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CHANGES - REV- 11 TO REV. 1 2 



Section 

1-3 Clarifies Sl/THETA project objectives without compromising 

product line objectives. 

9.0 No- lli - a reference for security design objectives- 

3.2-k-l Clarifies between sensing and recording in the power 
system. 

More precision on which disks are brought up by single 
button power-on. 

"tfuiet.izing" dropped as a generally required option. 
Feature matrix moved to section ll-l-S. 

3-5. fc». 2 Auto Power Recovery is to require a 2.5 second ride- 
through MG Set. 

3-2.b.M ' Further definition of short and long warnings. 

3.3- M 5> - Same function-i less implementation detail. 

1D> - Clearer terminology. 
n> - Eliminates redundant information. 

3.3.6. 2 Clarification of intent relative to compilers and 
compiler users- 

3.M-1 O.S. independence made a general product set requirement- ' 

3-M-2-1 In the matrix - added UPASCAL CUirth PASCAL}. 

1?> - Corrects compatibility objective of ALGOL bO 
relative to ALGOL bfl 

3-M-3-2 Classification "medium-, large and very large" revised. 
O.S. independence requirement moved to Section 3-M.l. 

3.5 CYBER IflO will comply with basis DoD security requirements. 

3.6 Maximum terminal capacity -Clogical> has been expanded. 

5-2.2-1 The Basic O.S. is also prohibited from source code 

release for system software security considerations. 

t-0 Dual State link is a 170/180 feature only. 

MMF shared peripherals restricted to RMS and Front-ends. 
User validation phased over 2 releases- 
Accounting phased over 2 releases- 
Tasking added to Rl- 
Job Dependency to R2- 

150 state Basic tape I/O and volumes to Rl. 
Online maintenance of tape in Rl via C170. 
Index Sequential to Rl. 
All of DBMS phased. 



Section 
7. M.M.I 



7.M.M.10.1 


7.5.1 


6.2.3 


6.M 


6.M.7 


6-k.M 


T.l 


10.M.1 


10.M-2 


11.1-2 


11.1.5 


11.2 


11. M. 2 



12.3.1 

12. M. 2-3 
12-5 
12.7.2 
12.7.2.2.5 



Two sentences were removed as irrelevant* 

1. Restricting objectives to Rl . 

2. Comparative CPU times- 

Paragraph removed - not directly related to objectives- 

BASIC speeds and benchmarks redefined- 

Uill support CYBERAMA- 

Clarification. 

MTTR average includes necessary trips for parts- 
Clarify assumption regarding degraded interruption- 

Clarifies critical PSR status of initial release. 

DoD Security Compliance is no longer excluded. - 

Clarification-, modification for performance is encouraged. 

Clarification of intent-, remote maintenance interfaces 
are standard-, the subsystem remains to be defined. 

2 port MUX is part of the basic mainframe in both C170 
and ClflO state- 

MG Set Options reduced to eliminate proliferation of 
development projects- 
Maintenance cost objectives stated in dollars and '/.. 

Minimum THETA configuration is MMB- Maximum defined 
real memory now is 32MB- 

Clarifies future terminals intent and relation to 
value added networks- 
System Power cost changes. 
Previous forecasts have been dropped- 
Schedul clarification- 
Some items delayed until fc»/7T. 



4 Change Summary - CYBER lflO AO/R Second Draft of Rev. C {Rev* 111 

Section 

1.3 Major Objectives - The specific areas of emphasis for 

Si and THETA have been noted along with potential for 
impact on priority trade-offs. 

1*3.1 The release dates for Si have been clarified. 

1.3-3 The base for perforwance measurement remains CYBER 73. 

2-0 Reference 10 has been updated and reference IS added. 

3.1- 1-1 Per request of Engineering the terminology for input/ 
output unit has been revised. 

3.1.1.2 The probable support of a two IOU configuration has been 
noted and a reference to varying memory capacities added. 

3.1-1.4 - Minor wording changes to reduce the confusion regarding 
common memory vs. shared memory {the latter is low cost 
communication medium for dual mainframe configurations 
only}. All other multi-mainframe configurations are 
independent of requirements for a common memory and the 
term has been dropped. 

. 3-1-5 Batch processing has been dropped in priority and further 
clarification on the relationship between transaction 
processing and time-sharing has been made* 

3.2.4 c> Clarifies the Si channel restrictions 

f> defines the 2 port console multiplexor and reserves 
1 port for remote hardware and software maintenance- 

3.2. 4. 2 Clarifies the PP's restricted accessing to central 

' memory as a software restriction. Clarifies PP software's 
relationship to controlware* 

3«2»4.3 Adds requirement for controllers to interface to the 
configuration environment monitor. 

3.2.4.4 Defines the minimum functional- characteristics of the 
basic operator control console** beyond which operating 
system or diagnostic software cannot use* Clarifies 
the role of the CYBER 170 CC54S console with regard to 
these requirements {the role of the CCS4S in ClfiO 
systems remains weekly defined. > 

3-2-b.l Temperature monitoring and power control need not be 
"internal" to a mainframe. Clarifies the use of the 
deupoint recorder, on 1B0 systems- Revises the power 
requirement for multi-mainframe configurations to greater 
power supply availability for shared elements. Clarifies 
motor generator sets options. 



Section 

3.2«b.2 Minor wording changes to clarify the role of automatic 
power recovery. Requires that automatic power recovery 
be implemented in a safe manner- 

3.2.L.4 The time constraints of short and long warnings are 
clarified. 

3-2. L- 5 CEM does not monitor ESM or EfS. 
Added bullet regarding one button 

power for equipment other than the basic elements-. 
.Clarifies the relationship of equipment monitoring and • 
power availability to peripherals in a multi-mainframe 
configuration. 

3«3»2 A reference to PP usage has been dropped {it was redundant 
to the earlier description}. 

3-3.4 The entire section-on Transaction Processing has been 
replaced. 

3-3-7 Sentence calling program structuring a subset of CYBER 170 
Segment Loader has' been dropped-i was misleading- The 
discussion of relative importance of loading performance 
vs. generalized library format has been clarified. 

3-3.6.2 The requirements for interchangeable file formats-* etc 
have been clarified to apply to compilers and system « 
utilities {removing the requirement from data management 
subsystems}. 

3.3.T-5 Functionally remains the samei the implication of multiple 
separate files has been removed. 

3-3.T.t Further modification/clarification to the accounting section^ 

3.3-10 A minimum configuration for pure 170 state has been added 
to support performance objectives in section 7. 

3»4.1 The applicability of these general product set technical 

requirements to interpretive compilers is clarified. Severa 
minor typographical corrections are made within the paragrap! 
The very last bullet regarding CYBER 180 system interface 
standard was redundant and removed. 

3«4-2.1 Requires that Class I-III compilers must all honor the 

System Interface Standard. Minor changes support levels 
in the descriptive matrix. Add transaction interface 
to the matrix. 

3.4.2.2 Clarifies FORTRAN'S relationship to ANSI standard. 

Restructures COBOL section with no change of content. 
Clarifies BASIC relationship between interpretive and 
object code generation. Several minor editorial changes 
made to the other paragraphs with no change in substance- 



Section 
3.M.2.3 

3.M-3-1 

3.M.3.1 

3-M.3-2 



3.M-3.M 

3. M.M-1 
3.M-M-3 

3.M.M.S 

3.k 

3. fa. 1.2 

3.t.2.1 

3.t.2.b 
3-t.3 
3,ft 
M.3 



Editorial changes have been made to improve clarity 
without changing basic content- "Random memory management* 
dropped - only a confusion factor. 

Requirement for a Direct access method has been added. 
{The Basic Operating System will no longer support a 
built-in Actual Key access method. > 

The last bullet regarding design trade-offs was removed. 
This information also appears in the design priority 
matrix. 

The DBMS requirement description of concurrent access 
drops "improved performance for key batch jobs." Dual 
logging and dual recording has been changed to a separate-! 
medium priority-i item. 

A definition of data base sizes has been added. Several 
minor editorial changes are made to this section. 

Data Dictionary System-Cs> allows a choice between one 
generalised or two specialized products- 

APL 2 replaces APLUM. 

Some priority changes have been made for DDL. All 
priority M's dropped. The paragraph has been flagged 
as preliminary. 

APL work space conversion utility has been added. 

The introduction has been expanded. 

The dual state requirements have been reorganized for 
clarity aqd generality. Some restrictions have been added-* 
and this section should be carefully reviewed. 

The objectives for CYBER 170 FTN5 conversion aids have 
been relaxed. The approach for CYBER 180 conversion 
aids has changed. 

The requirement to process 170 work spaces has been 
relaxed to the ability to convert those work spaces* 

File Conversion - this is a new section which replaces 
the corresponding section that appeared in AO/R Rev. B. 

This section has been expanded and some of the line speed 
requirements changed- 

The relationship between 17D arid 1BD maintenance software 
products has been reworded for clarity. 



Section 

5.2.1 "Minor degradation in performance" means compile speed. 

5-2-M Global cross 'reference listings apply to PASCALi SYflPL-* 
and the assembler. 

t.O This section has been completely rewritten in response to 

many questions. It should be carefully reviewed-! although 
it is still preliminary. 

7.0 The relationship of the Environments and Uorkload Spec 

to these performance objectives is described. 

7-1 The BMC60 performance base has been corrected -Cthe base 

line had been measured incorrectly on a CYBER 73>. 

7-2 Performance ratio for P3 PASCAL-X changed from 6.7 to 

B.M and special cases dropped to conform to the objectives 
in Rev- B. This section has been revised for greater 
clarity. 

7.2-3 The block copy performance requirement applies to all 
systems not just THETA. 

7.3.2 Requirement clarified to specify dual mainframe shared 
memory not a generalized common memory. 

7.M-2 Terminology for the IOU cleaned up. 

7.M.M-1 . Clarifies relationship of block and record sizes. 

7.M.M.3 Clarifies the number of exchanges permitted. 

7-M.M.M Eliminates abnormal termination and paging as considerations. 

7-M.M.1 This paragraph was rewritten- 

7.M.M.10 New section on Network Products Performance {with several 
changes from the earlier draft}- 

7-5.1 Uirth PASCAL added. BASIC production and development 

added. SYMPL field length requirements reduced and PL/I 
objectives deferred. 

7.5-2 THETA Math Library performance increased. 

fl-1.1-3 Cache/Map bypass does not apply to Si. 

fl.2.1r fl*2«2 Have been organized by responsibility area {hardware-* 
and fl. 2-3 software-i diagnostics or combinations} and minor editorial 
changes have been made- 

The requirement to repair memory concurrent with system 
operation has been dropped {it is not feasible}- The 
requirement to repair the second CPU of a dual CPU mainframe 
has been added. 



Sectio n 

a. 3. 1-1 
fl.3.1.2 

fl. 3.2.1 

fl.M.3/fl.M.H 
A.M. 7 

A. 5. 3 

A.t.2 
A.b.5 
1.2 

10.1 
10.M.1 



10.t«.2 



10. t 
10.7 



10. A. 3, 
10. A. M 



Applicable to mainframes only.; Subparagraph 3>A> clarifies 
off-line engineering file analysis capabilities. 

FCO's for THETA revised to more accurately reflect 
current schedule projections. 

First year software maintenance costs are increased 

to more accurately reflect the special support requirements 

or that early time period. 

System hardware maintenance cost objectives have been 
corrected -Cthey were previously calculated against the 
wrong base cost}. 

System lost time for OS interruptions has been changed 
to reflect processor speed. 

Clarification of parts availability. System availability 
objectives have changed due to increased THETA MTTR and 
reduced NOS/iao rerun time- 

'The DPSR objectives for Si have been divided into 
processor-, memory and I0U. Totals are corrected. 

Correction to Sort objective- 

New requirements on subsystem reliability. 

STAR100 as a computational facility will not be precluded • 
by current design activities. 

This section and its sub-sections have been edited for 
clarity-, and more detail. Minor revisions have been 
made-, as well. The section should be reviewed carefully. 

Ue may support the C1B0 parallel FMD on THETA/170 state. 
Minor changes in CMU interpretation requirements. 

a> the important distinction that a CYBER 170 lower 
system will deadstart and run an A170 deadstart tape 
rather than vice versa is clearly spelled out. This is 
an important distinction. 

c> clarifies PP access to central memory, 

g> makes on-line remote maintenance an objective for 
software enhancements to the A170 state. Note that this 
maintenance must use standard communications subsystems. 

Benchmark configurations have been added. 

Configuration cost adjusted for changes in component 
cost objectives. 



Section 
10. a. 7 

-10. a. i' 
io. a. a. 

11.1.2 
11.1. m 

11-1.5 

11.2 
11.3 



12.1 
12.3 

12.3.1 
12. M 

12. 5. S 

12.1, 

12.7 



Minor changes in availability objectives*! as a result 
of revised N0S objectives. 

N0S objectives modified. 

, The relationship between CYBER 170 and CYBER 180 
maintenance software objectives is clarified. 

Cost distribution between the basic Si and the 2 port 
MUX has changed. The total remains the same- 

The target manufacturing cost for the basic 10 Unit 
has been raised to compensate for added requirements 
on this product since Rev- A of the A0/R.- 

M6 Sets and power control panels added to this section 
with corresponding changes in the configuration appendix- 
Component Maintenance Cost Objectives have been revised. 

Previous error in THETA processor functional inherent 
MTBF has been corrected and MTTR increased to reflect 
the greater complexity of the machine- * I0U configurations 
having fewer channels than PP's have- been eliminated. 
■CNote-. it is jnot a requirement to have at least two 
channels more PP's. 

Development cost has been updated. 

Peripherals Supported has been revised to include C1B0 
O.S. release objectives and to make minor typographical 
changes. 

Terminal Supported has been added. 

Changes in response to cost objectives changed elsewhere 
in the document. Revises target communications 
configuration. More information on system power support- 
Most recent shipment forecast has been added. 
Corrections to schedule objectives. 

Appendix G - Migration Action Plan - a first preliminary 
plan has been added to this document. 



O.S. lost time assumptions revised. 
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Since there were some pervasive terminology changes in this document 
<e»g«i CYBER ISO superceded CYBER 60>i the automatic change bar mechanism 
of text editor did not work reliably. Ue have hand-marked those 
changes which are "worth mentioning". A summary of those changes 
follows: 



Section 

1.3-X 

1.3.3 

l.M 
2.0 

3.1.1.2 
3.1-1. "I 



3.1.2 



3.1.2-3 
3.2.2 

3.2.M 



a> Si target ship date has been added to this list. 

The speed objective for the high end 150 processor 
is now 31s x CYBER 73i and the paragraph disclaiming 
the Si system has been removed. 

An added emphasis on the long term nature of CYBER 170 
to CYBER 160 migration. 

References - Under 10> - the shipment forecast reference 
has been updated. 

Maximum central memory size changed from fe»Mf10 to 32MB. 

The requirement for shared common memory in all multi- 
mainframe configurations has been removed and failure 
mode requirements restated. The reasons for dropping 
common memory were configuration flexibility and CEfl 
and MCU control of shared components -(especially common 
memory>- 

The qualifying phrase "listed in priority order for 
design trade offs" has been modified to "for functiona l 
design trade offs". Ue hope this will clarify the 
intent to provide a basic design which will support 
transaction processing but not compromise time-sharing 
system performance- 

Communications/Networks has been moved to section 
3.6. 

Central Memory - In setting the THETA central memory 
cost/performance is not a driving factor. The THETA 
system is performance driven with manufacturing cost 
being a secondary consideration. 

I/O Unit -CI0U> - This has been restructured to incorporate 
the I/O Unit for the Si system as well as S2-. S3-. THETA- 
Some configurability limitations of Si IOU's are reflected. 
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Section. 
3.2. M. 2 

3.2.M.3 
3.2. M.M 

3-2.S 

3.2«t3.1 

3.2.b«2 
3.2.t-3 
3.2.k.4 
3.2.(3.5 
3.2.? 

3.3 

3.3.2 
3.3. M 
3.3.5.2 



ons« 



The paragraph on '"^""nltln^vSta. hTs'been'expanded 
ro°"orr cl K% C 1 lS s t r P a r e a ^ 9 in^^ m or those restrict! 

flulti-mainframe configurations will support shared 

access tapes- 

An editoriai cogent was removec .fro- the .first paragraph. 

r S prarcrpr b ^i f trin S c" 6 C rdr^ 4 rronsoie is introduced. 

similar to but cheaper than that of the iou 

A requirement for air cooling for SI ^. a ^ d ^ G f, e and 

requirements against tne puwei =>y 
configurations were added. 

Automatic Power Recovery - This was added in response ■ 
to a PLM requirement. 

System Initialization - The nature of the storage device 
• containing f irmware/controlware was clanged. 

-cir y in^ 

Performance Monitor - ™. optio"-l^-r fora.no. aonltor 
^ n a n n d^o b mpi!er^JorrrSui^;en T ts e was dropped. 

Operating System - Multiple processors were added as a 
mandatory hardware support requirement- 
System Code Organization was rewritten for clarity 
Transaction Processing - this is a new section. 
Real Memory Management - ^e paragraph showing th e 
distinction between antral and bulk and pr 
rnToLSr^ra^rmu^r-ainlraLSinking device. 



Cc 
cape 
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Section ' 
3.3.6. B 



3. 


.3. 


.fi.5.3 


3. 


>3< 


.T.t 


3- 


3< 


■ T 


3. 


3. 


,10 


3« 


M. 


-1 


3. 


M. 


.2 


3. 


4. 


.3 


3. 


H> 


M 


3. 


4. 


.4-1 



3-4.4.2 
3.4.4.3 

3.4-5 
3.b 

3-b-l 



Basic Record Manager - A distinction has been wade 
between basic record manager capabilities -[sequential 
and byte-addressable> in NOS/160 and advanced access 
methods which are part of DMSlBO- The objectives for 
basic record manager remain essentially unchanged. 
Index sequential and multiple index file organizations 
are part of the advanced access' methods. 

Unit Record Equipment - rewritten for clarity. 

Accounting - a bullet was added for support of 
application accounting. 

Networks - this was moved to section 3-B. 

Minimum N0S/1B0 Configuration - this was expanded to 
include minimum configurations for running dual state* 

A bulle't was added regarding the use of common modules 
within the product set- 
Languages - this is a new section outlining a general 
language strategy for the ClBO line* 

Data Management - this section has been significantly 
expanded from its predecessor. 

Design Objectives/Priorities - definition of execution 
speed was clarified. 

Language Processors - Sort/Merge and the Implementation 
Languages were removed. PASCAL and JOVIAL and ALG0L-b8 
were added. This PASCAL should not be confused with 
the implementation language-* PASCAL-X. 

Support Services - Sort/Merge was added to this paragraph 
and Advanced Access Methods were moved to data management. 

Data Management - this section has 

been completely revised in conjunction with the revised 

data management objectives. 

Utilities - Index Management dropped and Data Base 
Creation and File Conversion/reformatting added. 

Migration - the intent to add the migration plan to 

the CXflO AO/R is announced here- It is not part of this 

document but will be added before the final submission. 

Requirements for dual state 0-S- processing have been 
expanded and rewritten. 
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Sec tion 
3.t.2 

3.b.2.1 

3-k.2.2 

3.t.2.M 

3.L..2.S 

thru 

3.t.2.fl 

3.7.1 
3.8 

5.1 
(,.Q 



7.1 
7.2 

7.2.1 



The relationship of CYBER 170 SYMPL to product migration 
is reworded. 

The use of a CYBER IfiD common code generator for FORTRAN 
was introduced. The second section on breakages from 
.070 FORTRAN 5 has been expanded and rewritten. 

COBOL - some O.S. and data dependent breakages will 
be converted by the ClBO product and a C0B0L-5-mode 
compile option will be allowed. 

The ClfiO product migration assumptions for BASIC have 
been rewritten with the emphasis on conversion aid 
coverage being placed in the C17D product. 



All this material is new. 



On-Line Monitor - Bullet 7 added requirements to the 
independence of this on-line monitor. 

Networks - this is a new-, separate section consolidating 
.previous network comments- It is preliminary and will 
be extended for the final revision C 

The standards list is now Appendix H. ' 

Tools and Services - parts of the text of this material 
have been written as a result of a recent C180 tools 
working group. This section represents the latest 
understanding of tools requirements. 

Product Phasing Objectives - this section has been 
completely rewritten and reflects preliminary information 
with regard to all three ClBO software releases. Ue 
expect to have a detailed definition of the contents 
of Rl of ClBO software by 1<27T. 

System Performance Goals - Goals for the Si and THETA 
systems have been added. 

Processor Performance - Goals for the Pi and THETA 
have been added along with several new footnotes 
detailing assumptions for this chart- 

Memory Assumptions - assumptions for the PI processor 
have been added. There Qrq no assumptions or constraints 
applied to the THETA processor as is explained in footnote 



T to the preceeding section. 
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Section 

7. 2. a Cache Assumptions - PI and THETA have been added. 

7.2.3 Block Copy Performance has been added. 

7.3.1 Central Memory Requirements - have been added for SI 
and THETA- 

7.M.2 IOU Performance has been updated to include the Si IOU. 

7.M.M.1 Record Manager - the instruction count allocations have 

been raised to reflect clarification of a mis-understanding 
regarding CALL overhead and to represent a better 
understanding of the requirements for key operations- 

7.M.M.t Periodic Functions - a new section combining all known 
sources of periodic CPU overhead. 

7.M.M-B The loader performance requirements have been restated 
and movgd to this position. 

. 7. i|. i|.«| Dual state performance requirements are new and preliminary. 

7.5-1 Language Performance Level - an introductory paragraph 

has been added and objectives revised for several 
compilers- 

7.5.2 Requirements on FORTRAN and COBOL run time code efficiency 
have been consolidated into one paragraph. 

7.5.3 DMSlflO - performance requirements have been withdrawn 
and will be resubmitted at a later time. 

7.5.M Sort/Merge performance requirements have been separated 
from record manager time and raised. 

fi. 1.1-1 Duty Factors - the duty factor assumptions for peripherals 
have been clarified. 

B. 1.1-3 Component Criticality - some redundancy has been allowed 
for the IOU. 

6.1.3 Associated RAM Requirements - this is a new paragraph 
in response to the previous AO/R review comments. 

ft. 2 RAM Features - the cost/performance/reliability trade-offs 

for THETA CPU are outlined. 

ft. 2.1 The parity checking on major data paths requirement is 
less rigid for THETA than for other processors because 
of the very demanding performance objectives- 
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Section 
8.2.2 



B.2-3 

A.2.M.3 

8.3.1.1' 
8.3.1.2 
8-3.2.1 

8.M 
8.M.7 

8.5.3 
B.t-l 
B.t.2 

fl.L.4 
10.1.1 

10.1-2 



Capability to fault a PPU was added. The requirement 
to provide information for customer maintenance was 
dropped to discourage third party maintenance. The 
descriptions of supporting data integrity and continuity 
of system operations have been clarified. 

Micro-program control is .not, a THETA requirement- The 
description of the system maintenance panel has been 
dropped fro.m this section. The requirement that no 
operator intervention be required for deadstart recovery 
condition logging has been added- 

The first bullet under tests is a consolidation of 
two previous bullets reworded for clarity- The 
requirement for 1Q0£ protection of customer security has 
been added to "Tests" and "Diagnostics". 

Number of FCO's per equipment per year has been added 
as as information only item- 

The percentage distribution of PSR bug reports between 
the operating system and the DMSlflO has been changed. 

The objectives for hardware maintenance costs as a 
percentage of manufacturing cost have been revised 
downward. 



RAM Performance Objectives 
added thruout. 



Si and THETA have been 



Net Availability - the statement regarding rerun time 
has been changed to reflect use of fixed values in 
allocating rerun time against system net availability. 

DPSR rates have been established for THETA. 

DMSlflO has been expanded to reflect the revised plan- 

DMSlflO has been expanded to include the revised plan. 
The operating system and sort/merge product input 
data failure rates have been revised. 

DMSlflO PSR receipt rate has been raised. 

CYBER 170 Features Supported - this section has been 
reorganized for clarity and also adds information regarding 
instruction stack purging-* pass instructions used for A170 
features-! and maintenance support of ESM maintenance 
features- 



CYBER 17D Features Unsupported 
similarly to 10. 1-1. 



this has been reorganized 
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Section 

10.1-3 Advanced C170 Features - additional information added 
regarding the use of the PP in A170 state • 

10.M CYBER 170 State Software -^ this' section supersedes the 

previous one on compatibility and outlines the extent 
.to which C170 software will be modified and enhanced 
in conjunction with C1B0 hardware* 

10. S CPU Performance - PI and THETA have been added to this 

chert and S3 objectives raised. 

10.7 Mainframe Costs - Si and THETA have been added. S2 

and S3 were revised slightly. 

10-fl RAM - Si and THETA values have been added thruout. 

10. fl. 7 * Net Availability - Method of determining rerun time is 
redefined and Si and THETA are added to availability 
objectives. 

11-1 Component Cost Objectives - Introductory remarks on 

memory costs have been omittedi as no longer applicable* 

11«1»1 CPU's - Option for Ik KByte control memory for the P2 
has been dropped. THETA CPU costs have been added. 

11-1.2 Si System Cost Objectives have been added. 

11« 1*3 Memory - THETA memory has been added. 

11-1.5 Other - 752 console and SI interface to high performance 
console controller have been added. 

11*2 Component Maintenance Cost Objectives as a percentage 

of manufacturing cost have been revised. 

11-3 THETA and SI have been added to Component Reliability 

Objectives. 

ll-M-l Central Memory Sizes - Si and THETA have been added 
to this table- 

11.M.2 Central Memory sizes above 32 MB have been dropped. 

11-k Preventive Maintenance - Si and THETA have been added. 

12.2 Appendix B - Standards was moved to Appendix H. 

•CThe unnumbered pages caused human factors problems. > 
It was replaced with ClfiO System Objectives Summary 
which has been updated to include SI and THETA. 
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Section 
12.3 



12. M 

12. S 
12. t 
12.7 



Appendix C «■ Peripherals Supported - It is planned to 
support FMD parallel recording on a ClfiO channel 'in the 
C170 statei for THETA- 

. fiOOO and 20n0D0 line per minute non-impact printers 

have been added. 

* 

• tOD card per minute reader and 100 card per minute 
punch have been dropped. 

• tLfll-2 data channel converter costs have been revised. 

. ttifi3 channel coupler and CYBER 1B-5 batch terminal 
•have been added. 

Appendix D - System Configurations and Costs - the 
configuration information for Si and THETA systems have 
been added and the configurations for S2 and S3 have 
been adjusted. 

Appendix E - Shipment Forecasts - has been revised 
in accordance with various C150 program forecasts. 

Appendix F - Si System development milestones have 
been added. 

Appendix G - Migration Action Plan - this is a new 
section which will be furnished with the next update 
to this revision of the AO/R. 




En/H. Michehl 

Director 

Architectural Design & Control 
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.1.0 JMEGGUCJLIQfcl 



i.l BELUULiati 



These Architectural Object Ives/Requlrements IA0/R! define the 
generel goals established by CDC for the CYBER 180 CC1801 I lne» 
The goals for CYBER 180 hardware operating as a CYBER 170 IC170! 
(advanced CYBER 170, or C170I are In Section 10. 

Where sections contain preliminary Inf ormat lon f they are noted 
by the symbol* (#)• where they contain "Informational" 
objectives, they are noted by till. 

This document satisfies the requirement for Individual Design 
Objectives COO) documents for elements of the CYBER 180 I Ine, and 
supersedes all existing CYBER 180 and IPL 00*s. 

1.2 n "fJiiJfJbLL-flRSA NI ZA IlflM 

The Architectural Ob Ject Ives/Requlrements IA0/R) are In three 
partst the Introduction, which describes the system In general 
objectives form? the body, which describes the major functional 
elements and characteristics of the system In specific terms? the 
appenolces, which furnish detailed specifics of the system 
definition. 



1.3 JWiflRJLfliKLlIMES 

The major design objectives Influencing th« CYBER 180 are 
listed below In priority order* 

. TIMELINESS 

. RELIABILITY/AVAILABILITY/MAINTAINABILITY 

. SPAN OF PRODUCT OFFERING 



1 
2 
3 

«• 
5 
6 
7 

9 
10 
11 
12 
13 
iU 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2<i 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3V 
35 
36 
37 
38 
39 
%Q 
SI 
%2 
*3 
«♦«♦ 
US 
<i6 
*7 

<»« 



. COST/PERFORMANCE 

. USABILITY 

. PROTECTION/SECURITY 

. STORAGE STRUCTURE 

A balance among these general objectives Is to be maintained* 
No high priority factor Is to be allowed to compromise a lower 
factor below acceptable levels. 

The/ specific obj ect Ives • of low manufacturing cost for the SI 
and high CPU performance for the THETA system are to receive 
special emphasis. Any exceptions are noted In the text of the 
AO/R where Known, and will be fully defined In the specific 
products* 0R*s. 



1.3.1 TIMELINESS 



Several planning dates are key to the CYBER 180 oro>duct 
deflnltloni 

al Shipment of new hardware In CYBER 170 state - 

51 - 12/19/80 flnternal release! 
- 3/15/81 fexternal release! 

52 - 1/15/80 

53 - 11/01/80 
THETA - TBH 

b! First release of CYBER 180 state O.S. 12/01/81* 

Oeslgn trade-offs which cummulat ively affect the program 
schedule more than three months will be submitted tor upper 
management review and approval* 



1.3.2 RELIABILITY/AVAILABILITY/MAINTAINABILITY (RAM) 



It Is a requirement to maximize time between interruptions, to 
continue operations In degraded mode and to mlnltiza repair time 
and cost. Emphasis will be placed on software check Ing/recovery 
features and hardware assists to RAM Cto the extent of adding 
10-157 to manufacturing cost!. 
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1.0 INTRODUCTION 
1.3.3. i* Continuity 



Hardware redundancy will be required Tor higher MT3F 
con f Igurations* passing this cost to those users requiring it. 



1.3.3 SPAN OF PRODUCT OFFERING 



The hardware/software system Is to span a large range 

CI150-2000K In 1976 manufacturing cost terms! of configurations* 

applications and processing power. The line Is to encompass 

central processors of the range 1 to 36 times the speed of CYBER 

73. <In the context of this document* the CYBER 73 may be 
assumed to be equivalent to the CYBER 172* but the measurement 
base retrains CYBER 73.1 



1.3.3.1 Apjiiicailaas 



CYBER 180 Is to be cost /performance effective in support of 
general scientific and engineering applications. It is required 
to effectively function In network and data base environments and 
to allow user access In transaction batch or timesharing modes. 



1.3.3.2 CojmailtiiJUix-MiihiQ^Iba-UQft 



CYBER 180 Is to be compatible across Its range In §ourc« 
languages* Instruction sett data formats* recording media and the 
■-.user Interface. Feature and capab II Ity subset ting are accept ab le 
for high and low performance configurations* 

1.3*3.3 CojafflttQatlitY. 



To reduce development* manufacturing and maintenance costs* 
comion elements are to be used across CYBER 180. At least! 

£> Software product set 

9 Basic operating system 

r I/O channels and controllers 

- Peripheral devices 

*- Peripheral and controller diagnostics 

r Model-Independent testst e*g*» memory tests 

- Diagnostic utilities 

Additionally* CYBER 170 elements will be carried forward to 
the CYBER 180 line* where possible* 
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1.3.3.4 £aQjULQlilJU 



An Incremental progression In processing power, system 
throughput and system capability Is to be achieved throuqh 
harcware conf Igur abl 1 1 ty , specialized software scheduling 
algorithms and selective addition/deletion of software features. 



1.3.3.5 l!!LP.iflfl!*DlalJL2D^Ci2DJ.i:2i 



A broad range of applicability for the hardware/software 
products Is to be assured through specification and use of 
engineering standards* software conventions and common 
Implementation tools. 



1-3.4 COST/PERFORHANCE 



The CYBER 170's market strength Is high system throughput. 
This remains a major design factor for CYBER 18Q* however* the 
priority Is lower than It has been for CYBER 170 "systems. 



1.3.5 USABILITY 



CYBER 180 Is to emphasize usability by aopllcatlons 

programmers* Application programs are to be easy to develop and 

debug. The Interactive Interface Is to be simple to learn and to 
use. 

The major design criterion Is to define the essential features 
of the user Interface In a simple and consistent manner. Where a 
tradeoff must be made between NOS/NOS-BE evolution and 
simplicity* simplicity prevails. 



1.3.6 PROTECTION/SECURITY 



CYBER 180 Is to supply a basic level of hardware/software 
protection which significantly exceeds CYBER 170* More 
sophisticated security and checking features must b* furnished as 
software options* (It Is expected that a requirement for 
"certifiable security" will exist during the lifetime of CYBER 
180.1 
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1.0 INTRODUCTION 
l.«f MIGRATION 



1.3.7 STORAGE STRUCTURE 



A #3|or CYBER 180 objective Is provision of progressive! y more 
powerful memory and storage capabilities relative to CYBER 170 
and early versions of CYBER 180. This includes* 

- large real memories 

- virtual memory mechanism 

Longer range CYBER 180 objectives are to effectively support 
new storage technologies and storage hierarchies. 



1.% HlfiSAIIdM 

After having defined a product line which Is competitive in 
the warKetplace of the 1980'St migration of the existing CYBER 
170 customer base becomes a major consideration in CYBER 180 
definition. Conversion from a CYBER 170 to a CYBER 180 state 
system must be significantly less expensive than conversion to a 
competitor system. The migration Strategy will emphasize an 
extended period of conversion from CYBER 170 state fo CYBER 180 
state. 

The chief elements of the migration strategy are* 

at Hardware 

CYOER 170 State - CYBER 180 hardware Is to be capable of 
replacing a CYBER 170 mainframe and executing its code 
unchanged. Execution of the CYBER 170 instruction set on 
CYOER 180 hardware is defined as CY3ER 170 state. (Refer 
to Section. 10 for all objectives of the CYBER 170 state*! 

Peripherals - selected CYBER 170 oerlpheral devices and 
controllers will be supported In CYBIR 180 native state. 

b) Operating System 

Target Operating System - define a target operating system 
specification for CYBER 180 3nd then "bend" CYBER 170 
systems and products toward that target. The driving 
forces on the user Interface are simplicity and 
consistency. 

Multiple Job streams - Initial versions of the CYBER 180 

COMPANY PRIVATE DRAFT 
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operating system will support a dual-state CYBER 170 and 
.CYBER 180 Job stream. 

t 
c) Product Set 

Product Set Development - apply as much new CYBER 170 
product set development to CYBER 180 as possible feven if 
it means delays to the 170 program!. Advise users of 
recommended source and data usages which will ease their 
conversion to CYBER 180- 

User Programs - aim for source language compatibility 
between CYBER 180 and the equivalent iaM CYBER 170 
product. The driving force on the user interface is 
data/machine Independence. 

dl Data/Files 

A set of logical recording conventions will be established 
on both lines to ease file conversion. 
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2.0 EELEEEHGES 



1) Computer System Architecture Sub-Strategy (Revised 6/5/73) 

21 EOP Systems Strategic Plant 1977-1981 (Approved 7/6/771 

31 CPD CYBER 170 Software Implementation Plan (Network 
Products Information on1y)« October 1976. 

«•) CDC Market Requirements Oocument (11/10/76) 

5) Environments I Workloads Specification, ARH1858 

6) IPL Processor/Memory MIGDS** ASL00211 Rev. G 

7) IPL Hardware Maintenance Strategy* ASL00270 Rev* A 

8) CYBER Operating System Security Requirements and Status* 
August 3l» 1976* Daniel Zak. 

9) Large Computer Mainframe Reliability Growth Study* 
ll/22/76 f K.J.Bradford 

10) CYBER 180 Product Life Forecast* 0«#/l*/78* O.L^Mueller* 
B.L.Thompson 

11) CYBER 180 Program Plan, NPP Program Office 

12) CYBER 180/170 Maintenance Software Strategy/Otvelopwent 
Plan, U/tt/Ttf J.W.Sundet 

13) CYBER 180 System Interface Standard* $2196 

l«i) CYBER 180 Maintenance Objectives and Requirements* 8/2/77 

15) CYBER 180 Product Line Plan* F.Vlnce/B.L.Wlssner* April 
1978 



* Reference 6 is considered to be the base hardware specification 
for this AO/Rt although it now Is superseded by the CYBER 180 
Mainframe MIGOS* ARH1700. 
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16) DoO Oirective 5200. 28-M AOP Security Hanualt January 1973 
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3-1 £flfl£I£URAU$UJ£ 



3.1.1 HARDWARE CONFIGURATIONS 



It is the intent of CYBER 180 to achieve a smooth progression 
of computing power by offering a limited number of 
multi-processor and multi-mainframe growth options at each system 
level* This limited number of configurations Is chosen to allow 
simpler design and Installation characteristics to Improve cost 
effectiveness. Cost data for various configurations Is contained 
in Appendix D. 

3.1.1.1 IftnoiJLQoJLftgy. 



Terms to reference hardware elements* 

Halnframe = central processor!*) ♦ central memory ♦ I/O 
unit 

Mainframe system * Halnframe ♦ Peripherals 

Designators used to reference hardware elements fexceot 
THETAM 

Central processor = Pn 

Central memory = Hn 

Mainframe system » Sn 

Input/Output Unit = In 

where larger n Indicates increased capacity and/or speed* 
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3.1.1.2 Halpj.cajifl. .Systems 

A CYBER 180 mainframe system Is memory centered with emphasis 
on configuration growth and connectab 1 1 1 tyt 

- lM8yte-32HByte central memory.* Each memory accessible byt 

- 1-2 identical central processor units. 

- 1 lor (#) 2) I/O Unltst each consisting ofi 

- 5-20 Perloheral Processors IPP) 

- B-2<» channels 

* Varies by system type (see ll.k»ll 

3.1.1.3 Sec on flgucaklllty. 

Specific device classes may be required to run the system but 
not specific device models. 

Facilities .will be provided that allow for Incremental system 
expansion with minimum site disruption* It will be possible to 
add or delete peripheral devices from a running system, "^ 

Facilities will be provided that allow for dynamic 
reconfiguration around failed critical components (esoeclally 
CPU's in a two-CPU system t memory, and PP'sK 

It will be possible to power-uo and power-down all equipment 
without affect to the MTBI. In addition, Dower-uo ar\4 power-down 
Shall not require the assistance of a maintenance engineer. 

s.i.i.«i ttyitl-ma!DliLajDft-.£y-si£!ns 



Multiple mainframe system support will Includei 

• Job/file routing via I/O channel connections flocal or 
remote) to a dual CY3ER 180 or to a CYBER 180-CY8ER 170 
mainframe system. 

- Shared mass storage devices, magnetic tape devices, 
communications front-end, mass storage flics and 
Input/output queues ationg two to four mainframe systems 
running the CYBER 180 operating system. Jobs executlnq In 
different mainframes have the same file sharing 
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3.0 CHARACTERISTICS ANO FEATURES 
3.1.2.1 Software Feature Configurability 



capabilities as two Jobs executing in the same -mainframe. 
Jobs toy be dedicated to specific mainframes (e.g.* |obs 
using non-shared equipments or requiring a unique processor 
type!. 

In the general mul t l-malnf name configuration loose coupling 
le.g.f no direct access common memory elementl Is used for system 
control. An optional dual mainframe configuration using a shared 
area of one mainframe's central memory for coupling is 
supported* 

In the event of a single mainframe failure the remaining 
mainframes can continue to function In a multiple mainframe 
environment* In the event of a mass storage failure 
(device/control I erl only the failed physical element would be 
Inaccessible to the mainframe complex. Configurations that allow 
for dynamic reconfiguration around linK-medlum failures are 
supported. 



3.1.2 SOFTWARE CONFIGURATIONS 



The system will support concurrent processing In any or all of 
the following operating modes Clisted in priority order for 
functional design trade offsM 

6> transaction and limited time-sharing 
/• general purpose time-sharing 
• batch (remote and local! 

The intent is to provide a basic design which will suooort 
transaction processing but not compromise time-sharing system 
performance. All modes of operation must meet configuration and 
performance requirements. 

The system Is to be capable of optimization for a specific 
operating mode. Implementation of a t lme-cr I t leal operating mode 
will rot be specifically supported nor deliberately precluded. 

3.1*2.1 SoJLlnar £_Fe.a±uQ£_&aaIiguQakilliy. 



Software feature design and Implementation will support C0C*s 

separate element orlcing strategy. £ lJLsiilfid DliinSflC of major 

software features and products will be developed and offered as 
optional capabilities* The system deslqn will also allow for 
feature and capability subsettlng to achleva high performance or 
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maximum capability software configurations* 
3.1.2.2 Rfic^alJUiurjikJLlii* 



Reconfiguration of specific critical software components to 
obtain different system performance.) • capability and RAW 
characteristics will be possible in a user's running production 
environment. 
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3,0 CHARACTERISTICS ANO FEATURES 
3*2.1.3 Other CPU Features 



3.2 iJ4BJ3i[ABE.-£LE!J£NIS 



3.2.1 CENTRAL PROCESSOR (CPU) 



A series of CPU's are required to support a range of 
performance and applications; specifically, capabilities for 
Scientific, BOP and for CYBER 1T0 State. 

The CYBER 189 CPU will be based on the CYBER 180 Mainframe 
MIGOS, ARH1700. 



3.2.1.1 iQStLyJLlloji^SAi 



The native CYBER 180 Instruction set will handle tht 
applications above with emphasis ont 

linkage for switching control between CYBER 180 and CYBER 
170 state. 

floating point orientation* emphasizing execution speed. 

BOP orientation* emphasizing balance between instruction 
speed and code compaction. 

memory management* emphasizing protection and large 
address spaces* 



3.2.1.2 YicluaJL.H£iiiojQy.«tlficjiaiils!ii 



Provide a virtual memory mechanism to support a large virtual 
address soace by means of segmentation 9T}d paging. The mechanism 
Is to include protection schemes for inter/lntra Job protection. 

3.2.1.3 fl±bftCfce!l-£±alu"S 



ft Software managed f Interrupt driven processor. 

t Fixed suDoort to connect an optional performance 
monitoring facility Cnot to exceed 0.2X CPU cost* 
excluding real estate costs!. 

* Process separation fprotectlonl and memory interlocks. 

COMPANY PRIVATE DRAFT 
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r Procedure switching assistance. including stack 
operations. • 



3.2.2 CENTRAL MEMORY 



Central memory objectives arei 

SDan the product range (excluding THETAI with the best 
cost/performance. This imoliest 

. Exploiting the advantages of cost reductions in memory 
component technology. 

• Use of cache memory in the CPU for performance 
improvements. 

. Minimize cost/bit including cache costs tmemory 
volatility is acceptable). 

- Maximize availability throughi 

• Single Error Correction/Ooub le Error Detection Q 'j~ C /h 

• Reconf Igurabl I ity around faulty memory elements. 

Logical byte addressability 
3.2.3 (#> BULK MEMORY 

Bulk Memory objectives 8ret 

- Provide facilities to fully utilize bulk memory 
technologies e.g.? electronic beam access memory (EBAMI or 
bubble type device whan available. 

- Optionally support bulk memory to supplement central 

memory. 

- Bulk memory will be addressed In the same manner as central 
memory (Including execution). 

- Bulk memory will be non-volatile Cl.e. f retains Information 
2<» hours without power). Software will not comoehsaM for 
volatile media. 
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3.2.V I/O UNIT (IOU) 

The I/O Unit provides the input /output capability tor CYBER 
180. in 180 state, 170 state and dual state operations* The 
Driwary objectives are! 

- suDoort for CYBER 170 state. 

- support a high soeed I/O system architecture that performs 
most of the equipment oriented functions for the CPU. 

- provide connect abi I I ty to CYBER 170 peripheral devices* 

- provide flexible configuration options* 

To satisfy these objectives the IOU shall provldel 

a) CYBER 170 as a subset of the full peripheral processor 
(PP) Instruction set. 

b) Any combination of 5-20 PP*s in Increments of 5* 

c) Any combination of 6-2H channels in Increments of 2* 

- at least 1 channel per PP 

- both of a channel pair are of the same channel type 
1170 or 1801 

- SI supports only C170 channels up to a maximum of 22. 

d) Full cross connection between PP*s and central memory. 

e) Full cross connection between PP's and channels 

- United to 10 x 12 on Si. restricting Si/170 state" 
configurations to 10 PP's (one cluster) maximum* 

- 20 PP SI configurations (180 state onlyl require two 
channels for cluster Interconnection* 

- CYBER 180 state O.S. and maintenance software will 
restrict their use of full PP-channel 
interconnactabl 1 1 ty in anticipation of future models 
eliminating this capability* 

fl Provide a two-port operator console multiplexor tsee 
section 3*2. <♦.<♦) • 

- one port reserved for local operator console* 

- one port reserved for remote maintenance. 
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Peripheral devices supported in both CYBER 170 state and CYBER 
180 state use the CYBER 170 channel and unmodified controller. 
Changes in controlware and recording format are allowed for CYBER 
180 «ode support. * 

3.2.<i.i ChauaaLa 

The channel configuration allows connection of COC 3000 Series 
(via a CDC 6681 Oata . Channel Converter or equivalent). 6090 
Series. CYBER 70 or CYBER 170 perlDherals. In addition, a unique 
CYBER 180 channel will be provided that has the following 
capabl I It lest 

^ high transfer rate, see Section 7 

•• channel width of 16 data bits plus parity 

C cost efficient electrical transmission scheme for cable 
lengths up to 200 ft* 

*• error* detection. error Isolation. and ^rror reoortlng 
hardware which allows system RAM ob| ect I ves- to be met. 

3.2.U.2 EfidB!)£daJ_Rrjic.ft£5Jir.S. 



The PP's will be 16-bit processors that use the CYBER 170 PP 
instruction set. In addition. Instruction set extensions allow 
the addressing of all of central memory, and the efficient 
transmission of 8-blt oriented data. 
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The system function of monitoring for software and hardware 
errors or failures Is performed by a PP (On-line Monitor). 
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contro Iware 



(see 



C180 PP software will be treated as 
5.2.2.1). 

3.2.<i.3 Dfisticfi^Cfiolrjiilecs 



Device controllers will provide the following capabilities 
texceot where not aoproprlate to the device type)* 

- shared .access or multiple "data stream as necessary to 
support multi-mainframe systems IRMS» tapes and 
communications front ends onlyl 

- support several models of the same device or device class 

• attachment of up to 6*f devices 

* maximum overlap of operations on separate devices 

- single functional design for a device class 

- provide Interface to CEH for power control and 
environmental monitoring tsee 3.2.6.51. 



3. z.ti.<» §ftjfccalacJC£nsfli|i 



The operator control console for CYBER 180 consists of one or 
more interactive terminals which interface to the CYBER 180 OS by 
*eans of standard interactive terminal mechanisms. The Intent Is 
limited operator/system interaction. 

Basic operator control console functional characterlst les J 

- 300 baud for remote consoles 

- 9600 baud for local consoles 

- CRT screen of ZU lines by 80 characters 
• cursor control capability 

- standard ASCII Keyboard 

No CYBER 180 <nor new 170 state! operating system or diagnostic 
software will require functional capability greater than that of 
the basic control console to operate* 

Extended system status display capability will be available 
using more powerfulf optional display consoles? which provide a 
superset of the functional characteristics of the basic control 
console and which may .replace it. IThe current C170 CZ-5U5 
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3.2>(«.<t Operator Console 



console (only) will be allowed to fill this requirement on an 
exception basis. ) 

The operator interface will supporti 

- singlet multiple and remote ooerator console 
configurations. 

- minimum requirements for operator intervention fl«*.« 
design to execute in an unattended manner). 

- use of standard I/O interfaces and equipments for 
operator communications. 
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3.2.^.5 EficiBufical-lLfiyJLcfiS 



Peripherals to be supported are listed in ApDendlx C. 



3.2.5 MAINTENANCE CHANNEL 



There will be a Nalntenance Channel with the following 
characteristics! 

- Connect to the CPU'St memory* I/O Unit and other 
intelligent devices In the system. 

- Provide the' means for master clearing/Initializing the 
connected systnm elements. 

- Provide the interface for the Environment Monitor and 
Performance Monitor. 

- Provide a privileged access to the system for. maintenance 
and reconfiguration. 



3»2.6 HARDWARE SUPPORT FACILITIES 

There will be a set of hardware support facilities which 
provide the following functions) 

- Power-on/Envlronraental Monitoring 

- System Initialization 

COMPANY PRIVATE ORAFT 
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- On-Hne System Monitoring 

- Off-Line Diagnostic Control 
3.2.6.1 £o_agJL_S_*s.ie.ni 



The basic system will have temperature monitoring and power 
control local* to each equipment and operating Independently of 
all other system equipments. The basic system equipment 
requirements arel 

• - HG Set/Controller 

- Power Control Box (include dewpolnt sensing for liquid 
cooled system! 

- Environment ( temp/humldityl recording 

- Terminator Power Supply 

- Chilled water Is an acceptable requirement for S2 f S3* and 
THETA systems? SI must be air cooled. 

For operational convenience* it will be possible to power up 
the mainframe and certain peripherals from a single power-on 
button. This will apply as a minimum to all mainframe 
comDonentSt to all control lersf and to system disk drive and 
controller. The system will also Include a manual emergency off 
control. 

Multiple mainframe systems will be treated as separate 
mainframes each having their own power supply* either from their 
own MG set or from a single MG set via toad controllers. 
Elements common to these mainframes (e.g.* memory f disks* etc*! 
shall either have their own* independent power supply or use a 
single MG set via load controllers. 

MG sets will be offered either at minimum cost or with maximum 
reliability <to the system!. The high reliability sets will 
provide a 2 1/2 second ride-through capability. See section 
11.1.5 for detal Is. 

3.2.6.2 AuJLPJSallc, f ower_Rg£p_ftgxy. 

As an option* an automatic power recovery feature will be 
provided. This feature will have the following cgpabl I it lest 

- When the power supply Is Interrupted for a period not 
exceeding one hour* power will automatically be returned to 
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key system elements. 

- A deadstart signal will be, provided and a recovery 
deadstart can be performed without ooarator assistance* 

- Equipment sequenced uo will Include as a mlnlmumt all 
mainframe components? svsten disks, permanent file disks 
Bnd their controllers? remote terminal 
mul tlol exers/ front-ends (ie»» 25501 and other MGs? magnetic 
tapes and unit record equipment will be excluded. 

This option will require a Configuration and Environment 
Monitor (CEM) and 2.5 sec ride-through as Dart of the 
configuration. There may be legal imd icat ions which could 
nullify this objective. However. until these legalities are 
resolved, development snould assume the objective stands. 3nd 
desigr this feature with the approDrlate safety features. 

3,2.6.3 S*s_t£m_laUla±JL£iiHaa 
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The system 
roqulrest 

- A PP 



Initialization process begins In the IOU and 



A prestored program accessible by that PP from read only 
memory. 

A storage device containing th« f irmware/controlware for 
the hard-core system elements. Under normal operating 
conditions this will be the system mass storage device: 
otherwise it will be a removable media device tsee 
3.3.101. 
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3.0 CHARACTERISTICS ANO -FEATURES 

3.2.6.5 Configuration and Environment Honitor CCE1) 



- A console* as in paragraoh 3.2. *••<»• 

The prestored program validates the PP being Initialized and 
validates and provides the code necessary to read a record from 
the input device. The MTBF of these comoonents significantly 
exceecs the system HTBF and will not be less than 10.000 hours. 

3.2.6.* Syj&i£in_tlojiiiflrjLaa 

For hardware support monitoring in the on-line and off-line 
environment see Sections 3.7.1. and 3.7.2. 

All mainframe components shall be monitored for environmental 
conditions out of range. Mainframe components comprise! 
processors? IOU. memories (excluding ECS!, and ECS coupler In 
CYBER 1^0 state. Environmental conditions shall be* divided into 
two categorlesi 

SkoxlJiacQlaas 

These are warnings of an imminent failure* typically to a 
system critical element. which shall be reported by 
interrupting the CPU a minimum of 2.5 seconds before the 
f al lure occurs* 

JLo.Q3L.WaCQjLQ3S 

Long warnings are provided without interrupting the CPU 
whenever environmental conditions are such that an element 
may be exoected to oower down unless the condition clears* 
These warnings shall be provided 8 minimum of 2 minutes prior 
to power-down. 

3.2.6.5 £GQiigucanoji_and J£Q*icaom£at 

An optional Configuration and Environment Honitor will be 
developed that performs the following functlonsi 

- Monitors systems for environmental /power faults and 
warnings. When present In the system, the CEM will monitor 
the mainframe components for environmental/power faults and 
warnings. The minimum types of equipment to be monitored 
are (sea Appendix C for more detail!' 

- Processor 

- Memory 
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- IOU 

- System dlsK controller 

- System disk 

- Permanent file controller 

- Permanent file device 

- Base unit record equipment 
oriented) 



(batch or 



communication 



Monitors environmental status information from the computer 
room such as dewpolnt. power brown-out. etc. 



Oissemlnates alerts to processors that 
failure is imminent. 



indicate 



•system 



- Powers-up and powers-down mainframe components and selected 
peripheral equipment under program control as an energy 
conservation measure. 

- Provides one-button power on/off to equipment other than 
the basic group specified in paragraph 3.2.6.1o 

- Connects to a maximum of bh system elements or element 
groups (e.g.t a grouo of disKs or magnetic tapes!. 

In multiple mainframe configurations' 

- The CEM Is optional to each mainframe. 

- A mainframe monitors itself and Its Derloherals. 

- Shared peripherals are monitored by one mainframe only. 
Note that when one mainframe Is powered down the shared 
peripherals. will still be available to the other 
mainframe. However, if the mainframe which is powered down 
was responsible for monitoring environmental conditions on 
the shared peripherals. then they will no longer be 
monitored. 



3.2.7 PERFORMANCE MONITOR 



Except for SI the CPU will support an optional Performance 
Monitor hardware facility that collects data describing the 
dynamics of system execution. This data Includes measures of 
interrupt frequency, processor state changes, cache management, 
etc. that can be used in the analysis of system performance. 

Test points are furnished on the IOU to allow monitoring of 
external device and channel utilization by means of commercially 
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3.0 CHARACTERISTICS ANO FEATURES 
3.3 OPERATING SYSTEH 



available recording devices. Suitable test points will also be 
furnished on the SI. 

Performance Monitoring will be extendable* will not Interfere 
nlth the system when Inactive and will not violate system 
security. 



3.3 JQ££SAllb!&_iISI£!l 

The CYBER 180 operating system (NOS/1801 has the following 
design objectlvest 

1) Take advantage of CYBER 180 hardware capabilities* 

2) Hake user Interfaces! 

a) NOS/170 compatible, or 

b) Key migration Interfaces of NOS/170 may be mapped onto 
NOS/180 Interfaces through command language procedures 
or object library programs and services, or 

cl Extensions beyond NOS/170. 

31 Satisfy the needs of the software products* in priority 
orders 

a) FORTRAN Clnter3Ct lve, batch! 

b) Communications 
cl Data Management 
dl COBOL 

el BASIC 
t) APL 

Early releases of NOS/180 are primarily concerned with the 
migration of NOS/170 users* CYBER 180 hardware supoort will be 
phased across several releases. 

- dual state (CYBER 170 and CYBER 1801 

- large real memory 

- segmented virtual memory 

- rings of protection 

- I/O channel bandwidth 

- multiple processors 

MlaMv.JtesJLr.ab_jLSL 

- code segment sharing 
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- dynamic paging 

UaaJLcabia f 

- data segment sharing 

- two speed memories (central /bul HI 

- Key/locK protection 

CYBER 180 hardware and NOS/180 use multiple mainframes as the 
primary path for Increased availability with growth. NOS/180 
supports the distribution of ma|or system functions among 
separate mainframes or subordinate processors. 



3.3. i SYSTEM STRUCTURE 



NOS/180 has four malor functional elements* each with Its own 
objectives, guidelines, Interface rules and restricted set of 
functions. The elements arei 

II Monitor functions - the fundamental functions of software 
that translate hardware conditions and signals Into 
standard software conventions and data structures ' and that 
manage the CPU, NOS/180 and stand-alone CYBER 170 state 
require an implementation of monitor functlonsa 

Mj2DllCCjlb_ifiCjJLy.fiS 

- Correct functional distribution 

- Reliability of function 

- Speed. 

21 Basic Operating System (BOSI functions - basic functions 
most closely associated with managing system elements 
(Jobs, tasKs, files, memory, per iDhera I si . BOS functions 
ere primitive and are not directly interfaced by end 
users. PP functions are part of BOS. 

J&2_Qkl&CJLltt£LS 

- Correct functional distribution 

- Reliability of function 

- Speed of function and program call 
• Stability of Interface definition 

- Effective use of CYBER 180 hardware 

- Consistent and symmetric Interfaces for all elements 

31 Support Functions - general service functions available to 

COMPANY PRIVATE ORAFT 
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executing programs (e.g.* loader* basic record manager* 
operator communication! • These routines are structured to 
allow selective replacement by user or site supplied 
routines. . 

5UEflOXt-a& ifl C 1 JLgfl S 

- Performance of tha function and the program call 

- Reliability of function 

- Stability of specification 

- Adaptability to future change without forcing user 
conversion until the new feature is used 

*) Extended Operating System IE0SI functions - functions that 
manage the flow of work. EOS provides the command 
language Interface , to the end user. An NOS/180 
configuration may have multiple Instances of EOS* each 
tailored to the needs of different users (e.g.* 
transaction oriented application). 

- Ease of use 

- Adaptability to future change without conversion or 
retraining 

- Performance 

- Packaging 



3.3.2 SYSTEM CODE ORGANIZATION 



Where possible NOS/180 system functions execute In the same 
environment 3s user programs. System functions execute at more 
orotected ring levels* One copy of the code for these functions 
Is shared among multiple user programs* NOS/180 also supports 
many features in the manner of utility programs with mechanisms 
for adding, deleting and overriding these programs. 



3.3.3 JOB PROCESSING 



A Job is the major unit of worK managed by NOS/180. Users and 
NCS/lflO submit Jobs to perform work within the system. Resource 
asslgrment and usage accounting Is associated with a Job, Each 
Job ras a single owner and is known by a unique name. Access to 
resources and protected elements in the system is granted to the 
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owner of the Job. 

The Job deck/file structure resembles NOS/170? a 
command language statements followed by*dat3 elements. 



set of 



A Job step is the work done as a result of a single command in 
the Job deck/file. Job steps execute sequentially within a Job. 

A task is an Instance of execution of a program. Multiple 
tasks can execute within a single Job steo. Each .task has Its 
own address space (sat of memory segments). Tasks may be 
initiated either synchronously or asynchronously to the 
Initiating task. 

All. command language statements are processed within the 
environment of the Job. Terminal sessions are processed as a 
Job; login is Job Initiation and logout is Job termination. 

Jobs may submit other |obs for orocesslng. .NOS/H9 «prov ides 
commands to assist users and ooerstors In controlling the 
progress of submitted Jobs. 



3«3.4 TRANSACTION PROCESSING 



NOS/180 processes transactions using conceDts (user's 
viewpoint) similar to those of CYBER 1/0 TAF/NOS. Transactions 
are processed utilizing the tasking features of NOS/180. and 
permit transaction apolicatlons to have the same 3ccess to system 
resources (i.e.. tapes? files? databases* orivate D3cks. etc.! 
as do batch-mode and int eract i ve- irode Jobs. Transaction 
processing Is offered in NOS/180 In a manner which perrrlts 
tradeoff of performance versus features? and provides effective 
control of the system resources devoted to such processing, 

NOS/180 supports multiple transaction applications with 
concurrent access to shared databases. Individual applications 
may be remotely controlled by Application Administrators. 
Recovery of transactions is coordinated with data ma 

/■Amnnn Irat I nnr r\r> r\ Wur ♦ c «• n ?>c» ♦ t\ r» r* r» w 1 A a r% rur tan ui 



Recovery of transactions is coordinated witn data management and 
comrcur icatlons products so as to provide a system which features 
high integrity? continuous operation, and ease of use. 

While recognizing the need for high-performance transaction 
processing? CYI3ER 150 emphasizes the low to mid performance ranse 
in commercially-oriented applications. A basic transaction 
processing capability will be provided In NOS/180 R2? and. a 
competitive transaction processing capability will be provided in 
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NOS/180 R3. 

NOS/180 
fol towingi 



transaction processing objectives Include the 



1) Transaction .Prior If las«_ It will be possible to process 
transactions on the basts ot transaction priority within 
an application. It will be possible to alter a 
transaction's priority during Its execution. 

2) MHF .-Load-Leveling*, It will be possible to achieve 
load-leveling In e mul t l-ma lnf rame configuration by 
sharing an application's transaction load between 
mainframes. This will qo_L ba dynamic load-leveling. All 
transactions from a given terminal are processed on a 
single mainframe. Terminal connection Is made at LOGIN by 
NHP's Communication Supervisor* 

3) SloaiS. Owner* . Each transaction application will have a 

single owner. This owner will also own all resources of 
the application and will be accountable for all resources 
consumed by the application. 

4) lashL-GbaiDSi.- It will be possible for one task to Initiate 
another task or task chain* with the option of continuing 
execution or awaiting completion of the called task or 
task chain. 

51 JCfliniu.QlcjiJJLo.i3 BlficJSi.^. A variable-length data block may be 

passed from one task to another during a ♦ransacflon* 
This block may be saved between transactions* 

6) UhSoJ IcJtecL iQPUt... When an unsolicited input is received* 
a communication block will be prepared with the 
appropriate entries* and an Initial task will be 
Initiated. Applications will be capable of accepting 
unsolicited input while a transaction Is In progress. 

n ifiCtalQal £JLa±iJ&*L_ It will be possible for a terminal user 

to status the system at any time. A terminal user may 
receive the Input and output messages associated with the 
last successfully comoleted transaction for the terminal* 

81 i&Ji Hessage s* It will be possible to Initiate execution 

of a task as a result of a terminal being newly connected* 
reconnected during recovery* disconnected* or logged out 
from an application. 
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91 Standard Inter faces*,.. Transaction applications will use 
standard NOS/180 Interfaces* and will have the same access 
to system resources (e.g.* tapes* files* databases* and 
network products! as do other aop I leaf Ions. 

10) LflCJi Confrq I . , DMS180 will provide lock capabilities at 

record type and individual record levels* .Record types 
and records which remain locked but not accessed for some 
installation-defined timeout Derlod will be unlocked* 

ID QuletrPolnt. OMS180 will process Quiet-Point reauests. 
Most database failures will be recovered by OMS180 without 
user aDPllcatlon intervention or knowledge* 

121 £a.Q££l£G.b£CJsaoJLQi*._ OHS180 will process Cancel and 
Checkpoint requests. 3nd will ensure that "all or none" of 
each set of updates are performed* 

13) XfiSl flode. It will .be possible for Application 

Administrators to test selected transactions in a "live" 
environment without endangering databases* 

l 1 *) Database Recovery. In the event a database Is not fully 
recoverable! it will be possible to restore the database 
concurrently with other system operations* 

15) Message ,. Rout ing. , Terminals will be able to send messages 
and transmit files to a single destination, or broadcast 
to a number of destinations. Each destination (ray be a 
device* a user, or a network queue? and may be referenced 
by logical name* This facility- will be COC's Message 
Control System (MCSI offering. 

16) £ag£ Browslnot , Display terminal outputs which exceed one 

page (screenl will be queued, and an alert will be given 
at the terminal indicating more pages are available* The 
operator may access these pages randomly or sequentially. 

17) EoxEait£PlJL£Qj__ Application Administrators will be able to 
create new or modify existing screen Image definitions 
from remote consoles using Format Services* These i*age 
definitions will be used during format ted-screen 1/3. 

18) Off-Line Spooling. Terminal operators will be able to 
perform d iso I ay- to-taoe cassette operations in an off-line 
(local) mode* and later transmit the cassette messages to 
a host computer* 
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191 Termlnaf/prqtocpt Stfttttacii.-. NOS/180 network products will 

suoport the terminal types and fine protocols defined in 
Section 3.5 and Appendix C. 

201 Qlsfributed Processing. Transaction applications will be 
able to distribute their function and database throughout 
a computer network by routing messages to network queues. 
Message routing will be performed using standard NOS/180 
interfaces. 



3.3.5 MEMORY MANAGEMENT APPROACH 



NOS/180 use of the CYBER 180 memory organization has the 
following objectivest 

II Increase reliability and integrity of all software products* 
especially the operating system. 

21 Increase security and protection of user and system programs 
and data. 

31 Provide coverage of a broad range of configurations- 

<•) Increase flexibility to meet future requirements for new 
features and capabilities In an upwards compatible fashion. 

5) Share code and data among system and user Jobs. 

61 Support uniform addressing across code and data as experience 
and technology dictate. 

The memory of CYBER 180 Is managed at two levelst virtual and 
real. Virtual memory mechanisms provide the user's view of 
memory while real memory management. Is associated with the 
physical memory resources of a CYBER 180 system. 



3.3.5.1 Xinlyal-llMftat-llaQaaafliaDi 



Virtual memory tor user memory! Is a set of memory segments. 
Individual segments are units of protection and sharing within a 
task*s address space. 

Access to segments Is regulated by access mode control* ring 
protect ion# and key/lock hardware features of the CYBER 180 
hardware* Shared segments can have different access and 
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protection rights for each task # s address SDace. Segments can be 
transferred between tasks within a Job and can be paged. 

The system software is a set of segments* some of which aopear 
In every task's addr.ess space. This sharlnq Is r*3nage-d by 
NOS/180, 

3.3.5.2 Rfial.tlaiiiflCJt-JlaQaaaaifiLQt 

NOS/180 uses paging hardware to manage the allocation and use 
of real memory. Paging allows! 

1) Overcommitment of virtual to real memory. 

21 Performance ootimizatlon of virtual memory use. 

31 Memory degradation and partitioning. 

Job swapping Is also used to manage real memory. 

3.3.5.3 Cache Management , 

Soltware management of the CPU cache Is required when one 
processor accesses a segment that may be written Into by another 
processor. To avoid conflicts* NOS/180 bypasses cache ireffory for 
such segments. 

3.3.6 USER INTERFACES 



The user Interface supports a wide variety of users. NOS/180 
functions will be made available to as many access modes (e.g.. 
Interactive* batch* operator! as possible. These functions will 
be Identical externally within the constraints of functional 
socurlty and hardware* regardless of the mode of access* 

The NOS/180 command statements are a simple language that 
adheres to the CYOER 180 system Interface standard. The command 
language Includes* 

- Control functions to direct Job flow (e.g.* conditional* 
iterative and assignment statements!. 

- Functions that define and manage the Job environment 
through variables used by the command language and 
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executing programs. NOS/180 services use these variables 
(e.g.* file descriotions* program descriptions* Job step 
termination status) to interface between the user and the 
operating system. 

- Execution of programs and assignment of resources (e.g.* 
files? equipment* memoryl. 

- Execution of predefined sequences of command statements 
from procedure tiles. User command calls and command 
procedure calls are Interchangeable as need dictates. 

- Operator control functions. 

NOS/180 provides complete and descriptive status and error 
Information to -the user. • All status 3nd error information 
presented to a user is controlled by a system message generator 
utility. A user may select the level of detal I desired for 
Infomation messages received from the system. 



3.3.7 LOADER/LIBRARIES 



The NOS/180 loader loads object modules into memory and 
establishes linkages to other object modules* It accepts object 
modules output from compilers or the link-editor via sequential 
or library files. Multiple system and user libraries are 
supported. A default search list is unique to each Job (user) 
and can be modified during Job execution. 

The link-editor structures programs and combines object 
modules. The user structures programs to control the working set 
slzet to group modules functionally and to improve performance. 

NOS/180 provides source code and object library maintenance 
utilities. The packaging of programs and libraries is important 
to Derformance in NOS/180. The link-editor and the object 
library maintenance utility supoort this packaging process. In 
NOS/180 the objective is high performance loading from an object 
library in preference to supporting a broadly generalized library 
file format for source and object library files. Any library 
file is processable by the record manager and by the general file 
utl lltles. 
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3.3.8 INPUT/OUTPUT 



3.3.8.1 Tiles 



A file stores information (Jobs* data* programst libraries! 
within the system environment. It has one owner and is a primary 
object of security and protection controls. File access may be 
shared among multiple users at the discretion of its owner and 
users. 

NOS/180 supports permanent files (registered and saved for 
subsequent access) and temporary files (discarded at Job 
termination) • NOS/180 supports multiple cycles of a permanent 
file. 

One permanent file mechanism is provided. The user may access 
a file directly or lndlrectly f I.e.* a cooy of the file. 

Mass storage file labels describe the attributes of the file. 
The attributes Include file identification* file organization and 
structure* accounting Information* type of data as well as 
optional user information. The label is normally transparent to 
the user f but the user may alter attributes (those that will not 
cause Integrity or security violations) during the life of the 
file. 

NOS/180 supports automatic permanent file archiving and 
retrieval from tapes and the Mass Storge Subsystem. 

3.3.8.2 aasltL.Sfi.cord Maaaaac. 



The basic record manager supports sequential and byte 
addressable file organizations. The advanced access methods are 
described in section 3.*».3 on DMS180. The NOS/180 basic record 
manager design priorities aret 

1) Support the FORTRAN user (performance* simplicity) 

2) Provide an Interchangeable file format between oroducts 

3) Support the Oata Management and advanced access methods 
products 

*•) Support the COBOL user 
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5) Comply with ANSI standards. 

The basic record manager provides a consistent Interface to 
sequentially accessed files across all device types. There Is at 
least one interchangeable file format amonq users of all 
compilers and system utilities. 

Record manager provides record locHing facilities for at least 
one mass storage file organization in support of shared files 
modified by concurrent users. 

Record manager supports the record-partlt ion-file hierarchy In 
.a seauentlal file organization. These files are processed 
sequentially or randomly. Delimiters te.g.* record boundaries* 
partitions! and control Information (e.g.* compression* deleted 
records!" aro processed by the record manager. 

The NOS/1B0 system files are processable by the record manager 
and are recorded using one of the standard file organizations. 
For record oriented files there Is a single default file 
organization and record format that Is used by all compilers and 
utilities. 

3.3.6.3 pjixsical-Jnaul^QuiQul 



The physical I/O manager transfers data between memory and 
devices. A few primitive physical I/O functions are provided. 
They are device Independent! the same function Is defined for all 
devices and does the same thing for all where meaningful (If not 
an appropriate status Is returned!. 

Physical I/O transfers byte streams and Is unaware of the 
logical structure (e.g.* records! of the file. Files are 
recorded on permanent media (tape* disk! such that the system can 
recover partially destroyed files and determine how much data was 
lost. 

Physical I/O performance objectives are tol 

- Minimize disk access time or tape "start-up" time 

a! minimize the number of requests issued 

bl transfer as much data as possible oer request 

c> achieve overlap between I/O and processing. 

-• Take advantage of maximum device transfer rates. 
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- Provide seek and latency ooTlmlzatlon 
3.3. 8. k ifigffifiQt-.UejfeJ_Ac.C£5S * 

A file may be associated with a memory segment so that the 
data elements can be referenced as a byte string in memory. 

3.3.8.5 pevlce,. Hand lino 

3.3.6.5.1 MAGNETIC TAPE 

NOS/180 supports unlabel led taoes and ANSI standard labelled 
tapes. A file always resident on magnetic tape can be registered 
In the permanent file system. 

3.3.8.5.2 ROTATING MASS STORAGE 

Each rotating mass storage device Is self describing such that 
usage Information (e.g.* device label* allocation and flaw irao t 
file data) can be determined independent of information recorded 
external to the device. Flexible conf Igurat I on caoabl 1 1 1 les are 
provided to allow for onllna reconfiguration and nraintenance. 

NOS/180 requires all mass storage devices of the same type to 
have the same sector size. Different device types can have 
different sector sizes. '; 

Space is allocated on mass storage in terms of allocation 
units (one or more sectors!. The system dynamically assigns 
allocation units to a file as It is written. Th* user can 
optioralty specify the number of allocation units to be allocated 
to a file at any one assignment. NOS/180 also provides options 
to ©reallocate a specified number of allocation units to a file 
and to direct allocation to a soeclflc device. 

NOS/180 orovldes for removal and transport of mass storage 
devices within a system and between NOS/180 systems. A set 
conceot Is used to manage mass storage devices. A set Is one or 
more logically related mass storage volumes. One volume can ba a 
member of one set only. A set may contain one or more files* 
which may span volumes within a set but may not soan sets. 
NOS/180 requires an online system set for system files* queue 
flies and default residency for user files. 



1 

2 

3 

k 

5 

6 

7 

6 

9' 
10 
11 
12 
13 
1<« 
15 
16 
17 
13. 
19 
20 
2i 
22 
23 
2S 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3% 
35 
36 
3f 
38 
39 
*Q 
*1 
kZ 
k3 
ku 
«i5 
46 
k? 



COMPANY PRIVATE 



DRAFT 



COMPANY PRIVATE 



DRAFT 



CYBER 180 ARCHITECTURAL OBJECTIVES/REQUIREMENTS 
ARCHITECTURAL DESIGN AND CONTROL 



3-27 

06/08/r8 



3.0 CHARACTERISTICS AND FEATURES 
3.3.8.5.3 UNIT RECORO EQUIPMENT 



CYBER 180 ARCHITECTURAL OBJECTIVES/REQUIREMENTS 

ARCHITECTURAL DESIGN ANO CONTROL 

3.0 CHARACTERISTICS ANO FEATURES 
3.3.9.3 On-line Maintenance 



3-29 
06/08/78 



and remote unit 

Interface for 

This Interface 

Job control 

the NOS/180 file 



3.3.8.5.3 UNIT RECORD EQUIPMENT 

The NOS/180 batch facility handles local 
record equipment* It provides a unified external 
users and operators to local or remote devices. 
Includes Job structure* Job/file routing and 
comirands/dlspl ays. The batch facility uses 
Interface to access local and remote batch devices. 



3.3.9 SYSTEM MANAGEMENT 

3.3.9.1 g£&o_ucc&j£o.n.tr.Ql 

NOS/180 regulates all user access to system resources (e.g.* 
device assignment* memory management* media mounting!. Initial 
user validation based on user Identification and mode of 
ooeration (e.g.* batch* time-sharing* transaction! establishes 
limits for use of available system resource le«g«* devices* 
memory* CPU!. The user may schedule the use of resources within 
those limits. Resources are assigned and released dynamically 
during task execution. 

For named resources Ce.g«* mass storage files* tape files* 
volumes) NOS/180 maintains a catalog to associate the narre with 
the resource* to regulate access to the resource, and to store 
attributes of the resource and Its usage. Non-cataloged 
resources (e.g.* tapes! are also processed by NOS/180. 

Resources are made operational or non-operational at deadstart 
or by operator assignment or by the system error 
detection/recovery process. Operating system functions are 
provided to Idle down and free up devices. Non-operational 
resources may be assigned to val ldated maintenance |obs« 

3.3.9.2 ErxaL^aiaaQaslic.S-iQii-ElSLC.ayjLrjc 

NOS/180 emphasizes error checking and recovery. During 
execution NOS/180! 

- logs errors in the system engineering file 

- executes recovery sequences for peripheral equipments 

- reconfigures around failed components 

COMPANY PRIVATE DRAFT 
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3.3.9.3 fiQr.lLQe_HalDle.DaDCJl 



Maintenance/diagnostic Jobs may execute concurrently with user 
Jobs. These Jobs use standard Job and ooerator services -olus 
privileged operating system functions to assist in fault 
detection and Isolation. Initiation of maintenance/diagnostic 
Jobs and their use of system resources is subject to standard 
access control mechanisms. 

The On-line Monitor Is responsible for maintenance action when 
the Environmental Monitor .detects an Imminent s ysten/devl ce 
failure or when the IOU* processors or memory fall. If possible 
the falling element is dynamically reconfigured out of the 
system. 

When the system cannot function normally* the appropriate 
diagnostic sequence will be Initiated and the ooerator alerted. 
NOS/180 will attempt to save all Jobs in process prior to giving 
control to a diagnostic seqjence. 

3.3.9.«» £Y_slem_Qsids±anUSscai£exy. • . 

NOS/180 supports many configurations. The operating 
configuration Is established or altered at deadstart. Several 
levels of recovery from system crashes are provided (e.g.* 
recover Jobs from the last system checkpoint* recover Jobs In the 
swap oueue* recover contents of Input /outout queues). 

The on-line monitor alerts NOS/180 when a hardware system 
failure Is Imminent. The minimum level of recovery Includes Job 
and output queues* permanent files and all valid swap files. For 
an environmental failure the system Is Idled and a system 
checkpoint is taken ensuring the recovery of all Jobs. Operators 
may idle the system and Initiate the system checkpoint sequence 
at *ny time assuring recovery of the system environment after a 
restart recovery. 

Most system software is replaceable in a production 
environment without requiring a system deadstart. Some operator 
scheduling control Is required (e.g.* Idle the system! when 
charging the basic system modules. 
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3.0 CHARACTERISTICS AND FEATURES 
3. 3.9. 5 System Statistics 
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3.0 CHARACTERISTICS AND FEATURES 
3.3.9.6 Accounting 



3.3.9.5 ixslftfli-SJLallslics 



NOS/180 records usage and performance information on system 
files. This Information Includes^ 

- Job and system activities. 

-■ usage statistics* equipment errors encountered and types of 
system recoveries. For non-fatal errors (e.g.* solid 
single bit failures in memory)* thresholds prevent logging 
the same error repeatedly. 

- use of system resources and charge Information. 

- security events Ce.g.* access denials* user logins* 
configuration changes* access to secure objects*. 

- Job and system execution data for performance analysis. 

3.3.9.6 AcxouaHaa 



NOS/180 accounting provides detection* measurement* and 
recording of system use for the purpose of billing and cost 
recovery. This includes! 

- support for application accounting which allows authorized 
applications to unit price their services fe.g.* charge for 
the numoer of plots produced rather than the resources used 
to generate the plots! • 

- consistent accounting Information for each execution of a 
process based on a single billing unit that reflects all 
charges accrued by a Job. The single billing unit Is a 
function of detailed system usage Information that Is 
available to users and Installations personnel to support 
charges. The usage Information Is recorded In a set of Job 
resource and application usage counters. These counters 
are protected from direct access by a Job but may be 
Interrogated during execution with NOS/180 requests. 

- installation options allow tailoring of which resource* 
usage events or services are to comprise the billing unit 
and of the relative "weight" of each datum used in the 
billing unit algorithm. Authorized applications may also 
alter the "weight" of each* datum used In the billing unit. 
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accounting Information fop resources or services whose use 
Is controllable by the user Is available In "user" terms 
(e.g.* number of files accessed* dumber of linear equations 
solved) • 

support of a hierarchy concept of accounts, projects within 
accounts and members Cusersl within projects. Limits can 
be placed on accounts* pro|ects and users. 

support for billing and intei — Installation cost recovery in 
multi-computer networks. 



1 
2 
3 
S 
5 
6 
7 
8 
9 
10 
11 
12 
13 
IV 
15 
16 
17. 
18 
19 
20 
21 
22 
23 
2k 
25 
26 
27 
28 
29 
30 
31 
32 
35 
3V 
35 
36 
37 
38 
39 
«i0 
hi 
<»2 
UZ 

*5 
••6 

«*r 

48 



COMPANY PRIVATE 



DRAFT 



COMPANY PRIVATE 



DRAFT 



CYBER 180 ARCHITECTURAL OBJECTIVES/REQUIREMENTS 
ARCHITECTURAL DESIGN AND CONTROL 



3-31 
06/08/78 



3.0 CHARACTERISTICS AND FEATURES 
3.3.10 MINIMUM NOS/180 CONFIGURATION 
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3.3.10 MINIMUM NOS/180 CONFIGURATION 



Ratio of Workloads 1170/18*01 



100/0 

Processor 1 

Memory 1MB 

I/O Unit 1 

. - PP*s 10 

- Channels 12 

Mass storage spindles 2 
(100MB each! 

Removable device taot 
for system 
insta I lat ion 

Job Input device ' 1 

Job output device 1 

System console CC5%5 

3.H £EQnjiCJL.SE:i 



A ma|or CYBER 180 development constraint is to apply future 

CYBER 170 product set development to CYBER 180 wherever 

possible. Within that constraint* the CYBER 180 oroduct set 
ob) ect Ives arei 

1) Span 

Provide a single product set to span the CYBER 180 range 
without breaks In compatibility. Use common modules <code 
generators* run time libraries! where feasible. 

21 Migration 

Maximize user source code compatibility between the 
then-current CYBER 170 and Initial CYBER 180 product 
versions. 

3) Usability 
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Present a consistent external user Interface across the 
whole product set. Minimize local conventions and soeciat 
cases for one oroduct. f 

«i) Execution Efficiency 

Exceed product set parformance and reliability objectives 
established In Sections 7 and 8. 



3.<».1 GENERAL PROOUCTSET TECHNICAL REQUIREMENTS 



The following requirements apply to all product set members. 
Requirements on the production of object code do not apoly to 
products which generate no object code tincfudlng Interpreter!* 

Code sharing will be supported* 

• Product set members will be sharable (l«e«* one copy of 
code In memory at execution tlrce which Is utilized by 
al I users) • 

• Compiler generated object code will be sharable. 

Define and adhere to a common system interface standard to 
provide! 

• Object code communication across the product set fe.g.* 
a COBOL program can call a FORTRAN subroutine). 

• Common ob|ect text format to allow the linking of 
object programs produced by two or more compilers. 

• One or more record and file formats comiron across the 
product set. 

• One or more data representations common across the 
product set. 

• Compatible external user interfaces to all similar 
CYBER 180 product sef members* including the calls to 
all compilers* the output formats from alt coffpllers* 
and diagnostic massages from all compilers. 

Provide statistical* performance and system debugging 
facilities for both system and user level use. 

For produefs covered by standards In Appendix 9 (e.g.* 
BASIC* COBOL* FORTRANI* provide ootions to flag* accept 
and/or reject all non-standard statements. 

All compilers will aflowt 
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• Initiating a batch compilation by an interactive user. 

• Interactive communications with a terminal during 
execution of user programs. 

Common modules will be used where practical to provide 
reduced development and maintenance costs and consistency 
of results te.g., common math library and numeric 
conversion routines.) 

CYBER. 170 based products' wi I I retain their basic designs 
and techniques in their CYBER 180 implementations. 
Modifications are made according to the 'following 
guidel Inest 

• Existing functional structures Ce.g.t phases/passes* 
overlays! are retained. These structures provide the 
logical grouping of code and data needed to assist 
NOS/180 memory management. NOS/180 commands and loader 
directives that manage those structures are not the 
same as NOS/170. 

. NOS/180 loader tables are similar to CY9ER 170 and 
include separate sections for code and data. Loading 
functions interpret tables and organize code and data 
into separate segments. 

• Code is sharable among multiple users of a compiler. 
Separate data segments are assigned for each instance 
of execution. Product set programs are not aware of 
this sharing since it Is managed by NOS/180. 

• Product set programs manage memory within their data 
segments according to conventions defined in the CYBER 
180 System Interface Standard. 

• NOS/180 record manager Is used for input and output 
files. The Internal character data format is 8-bit 
ASCII. 



Product Set software tCompllers? Oata Management and 
System Utilities! Is to be as Independent from the 
ooeratlng system as possible. After the Initial 0.S# 

■- -._ .. ~U 4. i^__~ -.-. ^l^_-»_ _^». 



Produ 
S> 

ooeratlng .., — 

release* no new product release or re-release may 
require a new version of the O.S. If a particular 
feature requires special O.S. assistance* the 
remainder of the new product must still run on the 
previous operating system release. 
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3.*. 2 LANGUAGES 



The CYBER 180 language strategy Is oriented towards three^ key 
user languaqes* FORTRAN, COBOL and BASIC. Each of these 'has e. 
distinct' orientation towards scientific, business, and 
time-sharing respectively. The Importance of FORTRAN and COBOL 
in the rrarketplace is well-known, and both will continue COC 
strengths developed on previous machine lines. BASIC Is 
currently the most common time-sharing oriented language. 

These three languages wl 1.1 place a high premium on CY3ER lfO 
compatibility In order to ease user -nlqration, will have the 
stlffest requirements on performance f oar t Icul arl y FORTRANI , and 
will provide the fullest support of the language. Trade-offs In 
the operating system for product set support will be made In 
favor of these languages* 

Tre remaining languages will play more supporting roles In the 
CYBER 180 product offering. A possible exception to this Is APL, 
which is currently enjoying an increase in usage and could 
eventually equal dASIC In usage. 

3.*. 2.1 CQ.m_P.llar_..C!.aSSSS 



Another way of looking at the CYBER 180 language strategy is 
through the concept of compiler classes- This concept centers on 
the degree to which a language is supported and interfaced *lth 
the rest of the system. All classes will conform to the System 
Interface Standard. 

A Class I con?pl l.fic is fully supoorted and Interfaced to the 
system in terms of feature richness, debuqglng aids, usability. 
Interface to other systems, access to operating system features, 
etc. 

A £iass IX^Qnipj |ftr. is not fully supported In all aspects but 

nonetheless provides an Important language with heavy customer 
use. Certain characteristics will usually be stressed over 
others. 

A C|3ss, III comp j le r will be required to meet only the minimum 
language standards and will be Implemented and supported more as 
a free-standing application package. It Is meant primarily to 
respond to RFP - s and to be able to say we have it. A Class III 
compiler Is expected to use common compiler eiemenfs (e.g., 
common syntax table generatorl to the greatest extent possible. 
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even at the expense of performance* 

Usage trends for class II and class III compilers will be 

watched closely and the relative priority of these compilers may 

change, For example ALGOL-60» ALGOL-68, and PASCAL all may be 

able to satisfy the non-U. S. market Individually. If so f one 
will be picked and stressed over the others. 

The following chart breaks down the CY3ER 190 languages Into 
classes and provides more detail on the level of support provided 
by each. The languages are listed In decreasing order of 
priority. 
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H = extensive support 

H = iredium support 

blank = little or no support 

3.<».2.2 lodiidiJiuaL-LaDguasfiSi 



- FORTRAN 

This Is the most Important language for CYBER 180. It will 
provide both a production mode stressing execution speed 
and a development mode stressing compile speed and 
diagnostics? both modes will provide high-level ANSI-7T 
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suDDort. FORTRAN usage Is; expected to remain very high 
with virtually all sites using It? requirements will be 
driven by Systems. 

- COBOL 

COBOL is almost as important as FORTRAN. It will fully 
supoort the new ANSI standard. The expanded BOP 
Instructions of the CYBER 180 will make It much more 
performance competitive* The forecast is for Increased 
overall usage by our customer base! requirements for COBOL 
also come from Systems* 

- BASIC 

C100 OASIC, is intended primarily for Interactive use. 
BASIC will initially offer an Interpretive mode and later 
an option to produce compiled object code. It will conform 
to the new ANSI standard plus extensions for enhanced C170 
compatibility. Usage is expected to remain constant over 
the next 5 years* requirements come primarily from 
Services. 

- APL 



APL is intended for Interactive use* 



While the current 



forecast does not project an increase In use on C170 (stilt 
less than half of BASlCIt some Industry sources see a 
dramatic Increase In use In the 1980*s* 

ALGOL-60 

ALGOL requirements come primarily from Systems outside the 
U.S. Usage projections are not currently available? 
honaver, either PASCAL or ALGOL-68 could replace ALGOL-60 
and Its current position In that marketplace within the 
1932 timeframe* 

PASCAL 

PASCAL Is the language defined by Wirth* rather than the 
€190 Implementation language* PASCAL-X* It Is growing In 
popularity, particularly In the university end overseas 
environments* Requirements are driven primarily by 
Systems. PASCAL may oe the best choice to push due to its 
acceptance In the U.S. and its potential for replacing 
ALGOL In the European market. 
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- PL/I 

PL/I Is primarily Intended to respond to RFP*s and will be 
a minima? implementation* Requirements are driven 
primarily by systems* 

- JOVIAL* ALGOL-68 

If provided at all* the primary requirement would be to 
satisfy RFP's* Specifically these two compilers will not 
be planned for development from RIO funds* Development 
would be tied to specific accounts and funded at Ie33t 
partial ly from COS. 

JOVIAL could be one of three defined variants? J3» J 1 * or 
J7<«. The requirement for JOVIAL would come from certain 
U.S. Government contracts* ALGOL-68 is completely 
different from ALGOL-60 and would not be a reo I ace?ent 
unless marketplace abandons ALGCL-60 In favor of ALGOL-68. 
Requirements for ALGOL-68 would come from the overseas 
Systems markets* particularly from tha academic world. 

3»'*t.2*3 C^o^oji^ojTuiJLie.c^EljLiJiQla 

It is a CYBER 180 objective for compilers to share components 
Wherever possible and practical* and where schedule permits* 
Listed below are the major areas of commonality to be considered! 

- Common Code Generator (CCG) 

FORTRAN and SYMPL will both use the C180 CCG* COBOL* 
PASCAL-X, and BASIC will be designed so that they can 
eventually Interface to CCG* Other compilers will be 
required to use CCG unless shown to be Impractical* 

- Common Math Library 

\ All mathematical languages (F3RTRAN* ALGOL-60, PL/I* BASIC* 
I APL* JOVIAL) will use a common math library* including 
numerical conversion routines. 

- Common Syntax Table Generator 

This will be considered for all Class III* and pert-aos 
Class II compilers. This C3n simplify the syntax analysis 
phase of compilation at the expense of compilation speed. 
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Common Cradle Components 

The cradle code Is those modJtes used by compilers and the 
common code generator to perform service functions. These 
modules should shield the compiler from the OS Interface to 
provide a more easily changable set of compilers* Possible 
modules are I/O* control card cracking* cross reference 
maps* diagnostic interface* termination processing* etc* 
The use of common cradle modules must be enforced in 
certain areas for all compilers to achieve the degree of 
compatibility specified In the SIS. 

Common Debug Aids 

This covers such things as Interactive debug* tracebacK* 
and post-mdrtum dump analysis. All compilers are potential 
users of these common components* 
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3.«».3 (#) DATA MANAGEMENT (DHS1801 



The primary objective of OMS180 is to span the range of CY3ER 
180 processors and -applications with a set of secure* and 
compatible OMS capabilities. Target applications areas fray be 
supported by separate products rather than one data base 
manager* The compaf ibi I i ty across separate products will be 
aimed at uniform user interface conventions* utilities and some 
forms of Interchangeable media* 

The basic vehicles for DMS180 are CYBER*s OHS170 and EOMS 
systems* These products will be used as the design and 
experience base for selecting those OMS capabilities to offer as 
separate products in specific applications areas. Wherever 
feasible* existing CYBER 170 source code will be used to 
lfr.p leireht the elements of OHS180. 

The future need for ANSI compliance Is recognized although the 
current direction Is obscure* 0MS180 will sgoport one data model 
which Is oriented towards COOASYL and which will eventually 
provide a minimum level ANSI compliance. 
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File processing capabilities will include! 

- Advanced Access Methods {Direct* Indexed Sequential and 
Multlole Indexing! providing concurrent updating of 8 
single file by multiple users. 

- File Management utility supporting conversion between 
record manager files and to and from certain I 3N formats* 
as well as record qualification* ref ormatt lng» etc. This 
utility will be functionally equivalent to C170 FORM Put 
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will stress usability and consistency with other C190 DBN 
products over C170 compatibility. 

- Except where provided explicitly by the language (i.e.* 
COBOL) access to AAM files will be provided by a common sot 
of Interface routines for alt Class I and II compilers. 

3.^.3.2 Qata 9ase processing 



The C180 DBMS will be based primarily on EDMS which provides a 
3-level schema {conceptual* physical* and external) and 
COOASYL-type set processing as defined by the EOMS M C0SET M 
approach. A long term objective Is to provide support for the 
relational data model plus any CODASYL extensions required to 
meet the minimum ANSI standards* Support of a "0MS17Q View" is 
described in Section 3.6.2* Product Set Transition. 

The data base requirements described below define a 
•"traditional DBMS'* with little uniqueness over the competition 
with the exception of . the EOMS philosophy on Information 
processing and Its 3-schema approach. AOIC is currently 
investigating the desirability of additional 
requirements/capabilities In support of our key industries and 
the scientific orientation of our traditional business. Such 
additional capabilities would be Intended 1o provide a 
competitive edge in certain Key areas* rather than Just meeting 
the competition. 

CfitiS-.££I2JJJLCftGi£LQlS IHLCQXlflDLA 

- Concurrent access from transaction* batch* and High 
Interactive environments. In order to provide for 

ease of application checkout* and a better fit in 
the Services environment* the DBMS* as an optional 
capability should be able to execute In a 
non-concurrent mode. 

- System is to be geared towards the transaction High 
environment with the other two environments of 

secondary Importance* Usar Interface will be 
compatible across all three environments. 

- Host language Interface to all Class I compilers High 
(FORTRAN, COBOL)* olus selected Class II 

compilers where the need Is clear. DHL will be 
processed by a pre-processor rather than through 
modifications to the host language compiler. 
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Oata base Integrity. This Includes optional 
Integrity constraints to prevent orphan records 
from existing In the data base* Journal fogging 
and audit trails* and proper coordination of 
concurrent processing. 

Dual logging and dual recording should be 
provided as an option. 



High 



Medium 



Data base security. This Includes access control Hlqh 

to the item level* access controls on data dictionary* 

schema* and utility usage and display* and prevention 

of direct user processing of data base files (I.e.* 
circumventing the DBMS). 

Data base recovery. This Includes off-line recovery High 

using Journal logs and automatic recovery from 

system failures* with minimal operator Intervention* 

and on-line rollback of Incomplete t ransac t.l ons. 

Coordination of recovery with user-defined* 

operator initiated and possibly automatically 

tlrred quiet points Is required. 

Multiple data base supoort. The ability to process High 

multiple data bases concurrently* and to add and 

delete data bases without having to take the OTrtS 
down. 

Ability to "down*" certain parts of a data base for. Medium 
repair* dumping* etc.* without having to take the 
entire data base down. 

The OBMS access method will use* at a minimum* High 

the basic access methods of the C180 Record 

Manager. It will* however* be transparent to the 

user* I.e.* he will not be able to access the data 

base outside of the DBMS. Multiple access paths to 

data base records and data compression will be 

provided. 

0at8 Independence. Programs accessing data High 

bases Cor conventional files for that matter) 

will be independent off medium and device 

type* voluue residency* and storage structure* 

format and address. Data base programs should 

be insulated from changes to the physical data 

base (e.g., a program should be tied to its 
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3.0 CHARACTERISTICS AND FEATURES 
3.<».3.3 End-User Query Language 



external schema? It should not have to be recompiled 
when the conceptual or physical schema Is changed 
and the external schema does not!. Trade-offs 
should be made tn favor of Increased program and 
data IndeDendence over performance or Implementa- 
tion convenience* 

- Distributed Oata Base and Hul t l-Malnframe Support. Medium 
The DBMS must be able to support a shared data 

base by multiple mainframes. Some form of distri- 
buted data base capability will be required; the 
extent and exact mechanise Is not Known at this time. 

- The DBMS will be oriented towards medium 3nd large High 
size data basest but must be able to handle very 

I arge data basesi 

small up to 1 million bytes 

medium up to 100 million bytes 

large up to Z billion bytes 

very large up to 9 trillion bytes 

- Maintenance ease. The design of the DBMS shall Medium 
contain a maintenance mode to aid users Isolate and 
document software errors. Where possible these 

aids should work automatically without having to be 
turned on. 

- Training. Must adequately cover the Information High 
theory behind EOMS as well as the standard "how to 

use the product.** 

DBMS by Its nature Is a complicated product. It Is therefor* 
Important that design tradeoffs be made In favor of ease of use 
and simplicity of Installation over flexibility of caoabllltles 
and performance beyond the AO/R objectives. Reliability Is also 
very Important for DBMS as Its use generally requires a major 
customer commitment and Increased vulnerability of his operations 
to the system. In short* the DBMS should do what It does well 
and be easy to learn and use. 

3.«».3.3 Epj|H^sac-Qugr.v.-Lan^ua9fl. 



The C180 Query Language should appear to the user as a single 
product supporting both a conventional file and data base 
environment. First priority Is support of data bases, 
conventional files Is of secondary Importance. The query 
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language provides extensive query caoabllltles. a slmole uodate 
capability* and an expanded display capability providing at least 
headings* paging* and minimal formatting. The query language 
also Interfaces to the stand-alone report writer for more 
complicated reports* 

Query Language objectives include! 

- The existing QU language will serve as the base 
specification. This will be significantly reduced In size 
and complexity, and minimal extensions added to suooort new 
capabilities of EDMS and the expanded display caoablllty. 

- A common language for both tile and 03MS environments. 
Some language features will be restricted to one or the 
other environment. 



The query . I anguage should operate 
Interactive mode. 



In both 



batch and 



- Where possible the query language should share common 
modules with C180 compilers. This ensures consistency of 
numeric processing and conversion* and reduces develoowent 
costs. 

- A stand-alone schema for conventional files will not be 
provided. Instead, the description will come from either 
end-user directives or the data dictionary. 

- It would be .desirable for a user to be able to process 
files and a data base at the same time. This allows hi* to 
Interact between the two environments and to convert from 
one to the other. This has a low orlorlty and will not be 
done It It overly complicates either environment. 

Design tradeoffs In the query language will he made In favor 
of quality of code, and human engineering over performance and 
features. Where commands must taKe considerable processing time 
to complete* periodic statuses should be provided to 1<eep the 
user Informed of progress. 

3.«».3.«» QalaJUcJLLanacy. 

The C180 Data Dictionary SysterMsl will be used to describe 
both conventional files and OHS180 data bases. In the data base 
environment the data dictionary system will be Integrated with 
the data definition capabilities of the OBMS. 
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3.«».3.5 S«2QftClJiCJLl£C 



The C180 Report Writer will be a stand-alone package which 
will be able to produce reports from both the conventional file 
and data base environments. It would be desirable for the Report 
Writer to be able to function both independent I y* without the 
need for an initial processing step with the query language* as 
well as In conjunction with the query language where it 
simplifies user processing. Report Writer dlrectlvest where 
possible, will be compatible with their C17Q QU counterparts* 



3 . U • 3 . 6 Foreign Systems 



The system will not prevent the use of a foreign- data base 
management system, e.g.* TOTAL In lieu of the CYBER 180 OBM 
system. Foreign and CYBER 180 DBH systems are not required to 
share data bases but must be capable of sharing physical 
resources. 
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3.t».«i PROOUCT SET DESIGN OBJECTIVES/PRIORITIES 



The priority matrices which follow indicate resource and 
design trade-offs to be made in planning subject products. Given 
that a product meets minimum feature level and functional/RAM 
performance requirements* design and resource optimization should 
be ffade in a minner which emphasizes the higher priority 
trade-offs. The definitions of these design trade-offs are! 

COHPATIBLITY - Source level comoat lb 1 1 1 ty with the 
predecessor CYBER 1T0 product If no specification Is noted In 

"REMARKS". 

REAL MEMORY USE - The "working set size" Cor maximum overlay 
length) to process a nominally sized task (comDllaMon or 
other I. 

EXECUTION SPEED - For compilers* efficiency of generated 
object code in terms of CPU speed In executing representative 
sequences of code? for other products* CPU and throughput 
time to process representative product Inputs. 



COMPILE SPEEO - CPU and throughput 
Input. 



time to process source 



CODE COMPACTION - Efficiency of generated object code In 
terms of Instruction space necessary to execute 
representative sequences of code. 

TEST BASE SIZE - A wide range of user applications Is 
expected to be run against this product. Where resource 
trade-offs exist* they should be directed toward a large and 
comprehensive test base. 

FEATURE RICHNESS - Emphasis Is to be given to adding user or 

marketing requested features to this product beyond those 

necessary to minimally support standards and other products 
reaulrements. 
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REMARKS 



Compatible subs«t of 
C170 access methods 



Compatibility with FORM 



Execution soeed of 03MS 



Compatibility Hith 
C170 OU 



Compatibility with 
C170 QU 
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3^.5 UTILITIES TO BE SUPPLIED 



„—_.-«.._- — — - — — 

PROGRAM 1 Source code maintenance 
ORIENTED 1 Object code maintenance. 

1 LinK editor 

1 Line and text editor 

1 Text and source code formatters 

1 Oebugglng aids 


DATA 1 General utilities 

ORIENTEO 1 Copy (records, partitions* files! 
1 Compare 
1 File display 
1 Data management 
1 Index management 
1- Restructure/reorganization 
1 Usaga analysis 
1 Log/audit 
1 Recover/restore 
1 DO creation 
.1 File conversion/ref ornat ting 


MEDIA 1 Initialization 
ORIENTED 1 Dumo/restore 


SYSTEM 1 Maintenance log analysis 
ORIENTED t System use log analysis 
1 -Dump/load |ob queue 
1 System generation/modification 
1 Terminal use 
1 System/J ab/f lie status 
1 Message capability 
1 Permanent files 
1 Dump/load 
1 Audit 
1 Archiving 
1 Print memory or file 
1 Volume initial i*at ion 
1 User val idat Ion 
1 User accounting 


MIGRATION 1 APL work space conversion 
CONVERSION 1 Fl le conversion 
AIDS 1 Data conversion 

1 Program conversion 
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3.0 CHARACTERISTICS AND FEATURES 
3.5 SECURITY ANO PROTECTION 



3.5 S££.gfiUX-atlQ-£SQIECIIQH 



CYBER 180 wIH comply with section IV of O.o.D- 

5200-28M. 



Directive I 
I 



The security objectives for CYBER 180 software are to orevent 

II unauthorized access to Information 
21 unauthorized information modification 
3) unauthorized denial of use 

In an environment In which multiple users with multiple levels of 
clearance will be accessing and sharing computer resources* 
programs* and data which have multiple levels of accessibility. 



The five major components of the CYBER 
security capabilities are described below. 



180 operating system 



1) Identification - Every user of the system has a unique 
identification that is used to regulate 
access to the system and its resources. 
Interfaces are- provided that allow 
installations and users to regulate Job 
initiation and termination sequences. 

21 Control Access - Access control lists are the basic resource 
protection mechanism. They identify all 
legal users of a resource and the user's mode 
of access* Each resource known to the system 
has a single owner who Is responsible for the 
resource* Its usage* protection and 
accounting. A single module of code Is 
responsible for assuring that resource access 
Is In conformance with the access controls 
for that resource. Interfaces ar9 provided 
that allow Installations and users to provide 
additional control of user access to 
resources and Information. Access to 
resources is regulated according toi 

.the level of access of the user 
•the level of allowed access for a resource 
•the security level of the system 
envlronmentt both Internal and external. 

For example* a request for execution of a 
secure program by an authorized user could be 
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3> Integrity 

h% Survel I lance 
5) Protection 



prohibited If general purpose time sharing 
sessions are active. 

- The segment and ring memory protection 
capabilities of CYBER 180 hardware are used 
to control access and to Isolate the 
activities of concurrent users. 

- A system log describing security related 
events Is maintained. 

- optional data encryption Is provided. 

- The overall protection objectives for CYBER 
180 are to protect the user from other users* 
tho system from users* users from the system, 
and system elements fro* other system 
elements. 

- Data will be protected at the* 

- file level 

- record level (through Record Manager! 

- element level (through OMS1B0) 



3.6 jf) tllvRftllfltt 

Higratlon Is the process of moving CDC products and its 
customer base from the CYBER 1/0 to the CY9ER 180. It trust 
provide a set of CYBER 170/CYBER 180 product caoabllltles and 
conversion aids which will minimize the Impact of migration on 
the user base over an extended period (10 years). 

Initial CY3ER 180 hardware will be Introduced and supported as 
Advanced 170 systems which are caoable of replacing a CYO^R 1/Q 
mainframe and executing Its code. CYBER HO software (NCS150I 
will be Introduced later. 

CYBER 180 target specifications to support migration Includet 

- the definition of the user Interface for the operating 
system based on CYBER 1/0 NOS. 

- source language definitions that are the saire for CYBER 1/0 
and CYBER 180. 

- program and file conversion aids that assist the user In 
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moving to the CYBER 180* 

- a dual state execution environment wherein both CYBER 170 
and CYBER 180 workloads may be processed concurrently. 



3.6.1 OPERATING SYSTEM IMPLICATIONS 



3.6.1.1 fiUflJ_Sl3ll£-.ErJlCftSSl!ia 



NOS/180 processes either NOS/180 and NOS/170. or NOS/180 and 
NOS/BE 1T0 Jobs. The Initial design model for dual state 
processing Is that of a symmetric link conf Igurat Ion* one 
executing NOS/170** the other executing NOS/180. This sharing of 
a single mainframe is known only to the most basic elements of 
NOS/180. 



3.6.1.2 fluflLJtiata flgqulcfljiiftala 



The following dual state functions are provided through NOS* 
NOS/BE and NOS/180. Where tradeoffs must be made* NOS/BE 
migration and conversion supoort takes priority. Wherever 
possible dual state functions are symmetric between C170 and 180 
states. 

- Ability to submit a joo from one state to the other state. 

- Ability to status and control Jobs across the dual state 
from a terminal or operator console. 

- Ability to select C170 or C180 primary mode of execution at 
Interactive login 

- Support the symmetric link protocol between statest 
Provide standard requests to send and receive messages 
across the link. 

- Support for the C170 multl mainframe link functions (e.g.* 
get and save permanent files* route files* etc.1 for file 
access across the tin** 

- Provide mechanisms for OWNCODE exits on a file basis* 
Thyse exits will allow communication across the dual state 
link with system-supplied record access routines. 
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r Programs accessing files In the other state nqed not be 
recompiled when the file Is moved to the program's state. 
Control card changes are permissible. 

- Dual state operational control is orovlded from a single 
operator console Islmilar to NOS/BE mul t 1-malnf ramel whore 
NOS/180 dlsolays are a subset of NHS/170. At deadstart; 
memory, PP's and channels are assignei to the C17D state or 
C180 state until the systems are idled and a recovery 
deadstart is taken. Oual access controllers may be 
accessible by both states concurrently but not through the 
same channels* Oevica assignments may be snitched between 
states by operator control. 

- In a mul t 1-malnf rame environment external mainframes view 
the dual state processor as two mainframes and Interface to 
either the C170 or C180 O.S. directly via t he symmetr lc 
link. 

- Ouat state must support the following RAM requlrerrentst 

An O.S. failure In one state cannot cause on O.S. 
failure In th» other. 

Independent recovery deadstart Is desirable' Idle down 
of one state while the other Is being deadstarted is 
acceptable. 

One MCU/control facility supports both states. 

On-line maintenance, error logging* etc.* for NOS. 
NOS/BE and NOS180 are centralized. 

3.6.1.3 Qcecailna J^xslftOL-Uaac-Iiitfiiilats 

The CYBER 180 Operating System target specification is based 
on NOS/170* modified as necessary to present a consistent user 
Interface across the various modes of access and to accommodate 
new hardware features. On an exception basis* Important NOS/BE 
capabilities will be in the target specification. Subsequent 
CYBER 170 develooment will Dend toward that target soecl f lcatl on 
to achieve a more uniform user Interface when NOS/180 Is 
rel eased. 
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3.6.2 PROOUCT SET TRANSITION 



The objective Is to offer application source code 
compatibility between the CYBER 180 product and the CYBER 
170 J135J. products. This can be achieved byi 

- Implementing the product or front-ends on the two machines 
to a common external specification. 

- Using a common test base. 

- Carrying across the product Cor its front-endl written in a 
common Implementation language. 

The emphasis for— new- CYBER 170 front-ends and products will 
be to code in SYHPL for both CYBER 180 and CYBER 170 systems, 
i.e.? machine independent implementation. 

Existing CYBER 170 products tor those in development! written 
in SYHPL will be made more transportable by supporting SYMPL on 
CYBER 180. 

3.6.2.1 fPRIMK 



CYBER UO 8ase - FTN5 

- Successor to FTN«i 

- Breakages will be Introduced to reduce erachlne and data 
dependent usages. Usages such as SHIFT and MASK 
operations. Hollerith data* etc. will be flagged and 
require manual conversion. 

- Breakages will be Introduced for ANSI compliance and to 
remove archaic usages* 98£ of the Jobs so affected will be 
translatable by conversion aids 

CY8CR 180 Product 

- FTN5 reimplemented in CYBER 180 Ircplementat Ion Language 

- Use common code generator 

- Same external specification and test base as CYBER 170 
version 
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- Machine and O.S. dependent breakages only. A conversion 
aid will be provided to flag possible machine dependent 
usages for hand translation and to convert O.S. dependent 
breakages (e.g. t OVERLAY) where possiole. 

3.6.2.2 ££ag_L 

CYBER 170 Base - COBOL 6 

- COBOL 5 f extended to meet ANSI-79 requirements 

100X conversion aid coverage of C080L-5 to C0.3CL-6 
breakages 

CYBER 180 Product 

- C0B0L6 Front End transported to CYBER 180 

- New code generator 

- Breakages only In areas of O.S. Support and machine 
dependent data tyDes. A conversion aid will convert all 
those breakages that can be converted? those that cannot 
will be flagged to aid in hand translation. 

- Control card ODtlon to compile C170 COBOL 5 programs as 
required by new ANSI standard. Hill work for all programs 
unless unsuDPorted system capabilities used or machine 
dependent data manipulation done. 

3.6.2.3 SQfcUHESGE ' 

CYBER 170 Base - SORT/MERGE 5 

- New compile phase meets CYBER 180 System Interface 
Standards 

- S/M5 processes old end new sort directives, no conversion 

aids 

CYBER 180 Product 

- S/M5 compile phase 

- New sort phase 
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No conversion aids other than system utilities for fife 
conversion. 

Oreakages in areas of OS support and data dependencies. 



3.6.2.4 BASIC 



CYBER 170 Base - Interactive BASIC 4 

- New Implementation? runs interpret lvety and produces object 
code 

- Modest feature enhancements to 1977 BASIC 3 

- Removes semantic deviations from ANSI-78 BASIC 

- 10QX conversion aid coverage for data-independent language 
differences. 

CYBER 180 Product 

- BASIC 4 front end and interpreter transported to CYBER 180 

• Compliant with expanded. ANSI standard? retains 
non-conflicting extensions from CYBER 170 BASIC 4 

- Very few breakages and only In area of O.S. support? all 
of these will be diagnosed by the compiler. 

- No object code available from early version. 
3.6.2.5 ALGQL-6JL . 

CYBER 170 Base - ALGOL 5 
CY8ER 180 Product 

• ALGOL 5 front end transported to C180 

- Machine and NOS/180 dependent breakages to be diagnosed by 
the compiler 
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3.6.2.6 A£L 

CYBER 170 Base - APL2 CAPLUHI 
CYBER 180 Product 

- A new implementation compatible with APL2 CAPLUHI 

- Breakages only .in areas of O.S. suoport and machine 
dependent data types 

- Hill be able to convert C170 APL work spaces and files 

3.6.2.7 £A^£ALi_>;QVIALt,ALSQLr&ai,.gUI 

The CYBER 170 base for these products is too small to warrant 
special migration planning. 

3.6.2.8 QfiiifiUs an JUgcanao ££caducjL_Icis QiLtJjm 

OHS180 will be designed to suooort a "OMSiTO View" to helo 
ease user migration. Providing a 100X compatible DMS170 Vie* 
will not be possible in either the OJL or OML • The m^for 
emphasis will be placed on migration of user source orogrgms and 
sub-schemas wherever possible. The actual Implementation 
decision will be deferred until 19*1 and will depend on the 
number of active users of C0CS. 

The approach will be to translate existing COCS data 
structures (relations! Into the equivalent DMS180 structures 
(sets). A conversion utility will translate COCS calls within 
user COBOL and FORTRAN source programs Into eaulvalent QMS 1.10 D^L 
statements. The OMS170 data model will not be processed directly 
by DKS180. Some form of conversion aid will be required to 
convert a data base from DMS170 to DMS150. 

3.6.3 FILE CONVERSION 

3.6.3.1 SJLIzUaS 



A symmetric (between C180 and C170I set of copy and conversion 
utilities will be provided for taoe-to-tape and 
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dlsk-to-tape-to-dlsk file conversion. They will handle! 

a) All access methods and record types supported by C170 
Record Manager (Vl.*» and VI. 51. 

bl All CITO character codes to/from ASCII. 

c! C170 18-blt Integer to/from C180 half word. 

dl Full word Integer and floating point. 

e) ANSI 69 (read only) and ANSI 76 labels. 

f) 7600 SCOPE 2* Sequential and Word Addressable file 
organlzet ions. 

g> 3000L* MASTER Sequential and Linked Indexed Sequential. 

3.6.3.2 flQ^LiQft 



When executing in dual state* a program may access disk files 
froir the other state. Access to 170 files from the 180 state is 
mandatory. Access to 180 files from the 170 state Is required 
unless that access is demonstrated to be seldom-used or 
prohibitively expensive to Implement. 

3.6.3.2.1 SYSTEH SUPPORTEO 

2l£3±ft Stela txca (character % Integer or floating point) 

files can be accessed on a file or record basis. 

a) Files of the following types may be transmitted* in their 
entirety, between states! 

- Sequential organlzat ion* record type H or Z* block type 



b) Files of the following typ€s may be designated for 
record-level access between the states! 

- Sequential organization* record type H or Z. block type 
C 

- Index Sequential. 

* 6-blt, one code type for 170, 8-blt ASCII for 180. 
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3.6.3.2.2 USER INTERVENTION 

Cn a file basis, OWNCODE exits will be suooorted which allow a 
user to request a raw binary record from the other state* convert 
date fields as necessary and return the record to its requesting 
program. (Disk) file types to be supported are! 

- Sequential 

- Indexed Sequential 

Any CYBER 170 file can be accessed on a PRU basis. An entire 
file or a single PRU can be transmitted between states*, The user 
program or owncode exit is responsible for interpretation and 
conversion of the PRU content. 



3.7 HAIMEMMfiE^SQFTHA&E 



Maintenance Software is organized into three major categories! 

1) On-line Monitor . 

2) Off-line Monitor 

3) Tests, Diagnostics and Utilities 

The functional objectives for CYBER 180 Level II and III 
Maintenance Software are described In the following paragraphs. 
These objectives aDDly to both the CYBER 170 and CYBER 1U0 states 
o? operation except where noted otherwise. 



3.7.1 ON-LINE MONITOR 



The CYBER 180 state On-line Monitor 
*alntalnabl I lty of system critical elements by! 



shall 



l^orove 



1) Observing system operation via hardware RAM features. 

2) Reoortlng and logging errors. 

3) Actlvate/deactlve hardware RAM features as requested by 
the OS and/or tests and diagnostics. 

«i) Notifying OS of hardware failures. 

5) Being designed to function In a "crash-proof* 4 manner to 
ensure retention of pertinent failure data. 

6) Providing a console interface to the maintenance engineer 
both locally and remotely. However does not supply the 
remote access driver software. 

7) Monitoring system mainframe comoonents (processors. 
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memories* IOUI for environmental power faults and 

warnings. It shall be Independent of hardware failures* 

except Its own, and Independent of Operating System 
fal lures. 

In addition* the on-line monitor shall* 

- Limit the. equipment dedicated to the on-line monitor to a 
maintenance channel and PP for CYBER 180 state* and to a 
maintenance channel for CYBER 170-state. 

- Be logically Independent from the system. A failure of 
these facilities wilt not cause a system failure. 



3.7.2 OFF-LINE MONITOR 



The Off-line Monitor shallt 

1> Provide a load and control capability for both CYBER 180 

and CYBER 170 tests and diagnostics. 
21 Provide ability to examine failure Information on system 

critical devices as collected by the On-line Monitor. 
3) Suoport verification* manufacturing* and the field 

environment. 
%) Support remote maintenance. 

51 Provide for total system exercising and verification. 
61 Provide capabilities for mainframe Initialization. 



3.7.3 TESTS, DIAGNOSTICS* UTILITIES 



II Detect* Identify and Isolate hardware malfunctions In th* 

CYBER 180. 
21 Verify hardware operation prior to customer use and after 

repair. 
31 Where possible* be able to execute In an on-line and 

off-line mode. 
U) Provide equipment and media performance history* analysis* 

and predictions. 
51 Provide maintenance procedures based or> performance 

history. 
61 Provide "truncated" versions of CYBER 180 tests tor 

initializing the hardware needed for on-line or off-line 

system operation. 
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3.6 UfiDiQSKS 



CYBER 180 network products support data transmission among 
host comouterst and between host computers and terminals over 
corarrunlcat ion lines. Single and multi host configurations are 
supported using the CYBER 170 Network Processing U.nlt C255X or 
successor) hardware and software products. This Interface allows 
the addition of a CYBER 160 host to an existing CYBER 1/0 
network. 

The CYBER 170 host network software is the base of CYBER 160 
host software. The Network Access Method (NAM)* Communications 
and Network Supervisors (CS, NS1* and Network Oeflnltlon Language 
(NDL) Imolementat Ions will be used where they meet the structure 
of NOS/180. NAM will have a dedicated PP to interface to the 
front-end NPUs. The Remote Batch Facility IR3F) will support 
local and remote batch devices. 
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The terminal types and line protocols supported are described 
in Appendix C. Asynchronous lines may operate at standard rates 
between 110 and 9600 bps. Standard speeds are 110* 13«*.5« 300, 
600, 1200, 2<f00* <*800 and 9600 bps. Synchronous lines may 
operate at speeds between 2000 and 56*000 bDS. Inter-node trunks 
may operate at speeds up to 56*000 bps lor higher if general 
Industry trends dictate). 

The NOS/180 file interface can be used by user and system 
applications to access network devices. This allows a program to 
handle network and non-network devices with one Interface. 

Support tools for managing Network Processing Unit software 
are provided with NOS/180. 
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«#.0 £5HMIiaiLIIUaiU£ClIIit£S 



*.l JflTHIFLCIttEBUM 

CYBER 180- will present a compatible data Interface that Is 
accommodated across the line. This objective includes provisions 
fort 

Single instruction set across the CPU range. 

ANSI standard data representation on cards and tape. 

CYBER 180 standard data formats (internal and external !. 

• CYBER 180 standard disk recording formats (physical and 
logical file level) for each transportable media type. 

- CYBER 180 standard operating system interface. 
The CYBER 180 standard data formats arei 

- 8-blt bytes. 

Internal representation of character data in ASCII* with 
special CPU provisions to take packed decimal data that 
had been previously translated from EBCDIC to ASCII and 
translate It back to its original reoresentat ion. 

• Fixed point numbers* 32 and 6% bit H's complement 

• Floating point numbers* 6«*-bit (single precision! and 
128-bit (double precision! signed magnitude. The results 
of the CYBER 180 floating point instructions will be 
arithmetically compatible to the normal range of CYBER 170 
floating point normalized unrounded results. 

Signed and unsigned packed decimal numbers. 

Signed (embedded and separate/leading and trailing! and 
unsigned zoned decimal numbers. 
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It is a goal of the Maintenance Software to use certain 
existing CYBER 170 maintenance programs. This software shall 
have the same external diagnostic/test procedures when run 
either in the CY3ER 170 or the CYBER 180 state. 
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Level III Maintenance Software must perform 
operating systems supported in CYBER 180 state. 
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5.0 SYSTEM ENGINEERING 

S.Z TOOLS/SERVICES FOR CYBER 180/170 DEVELOPMENT * MAINTENANCE 



5.0 51ST£H..EM£lME£RIHfi 



5.1 STANDAfrOS 



The CYBER 180 systems will comply with at I applicable COC and 
Industry standards* Any deviations will be identified with 
waiver statements in product design documents. See Appendix H 
for the full standards list. 



5 . 2 iJH3is^m&E^E£ajuaEg~iiaai^ 

This section gives general direction for managing the design 
and development of the set of software tools to be used in the 
migration of our software sat from CYBER 170 to CYBER 180. 

The design objectives for Tools and Services will be - In 
priority orderl 

1» AJLlaii product set members spanning the CYBER 170 and CYBER 
180 ooerating systems to be developed and maintained in 
one form 9 using the same tools. 

2) Support the development and maintenance of products to be 
used in a dual OS state environment (CYBER 170 state and 
CYBER 180 state). 

31 SuBfiOCi the retirements of the CYBER 180 OS development 
project and their language* PASCAL Extended (PASCAL-XK 

<v I £as£ the transition of CYBER 170 trained programmers onto 
the CYBER 180 system. 

The CYBER 170 will be the primary software development vehicle 
for early roleases of CYBER 180 software. Both ARHOPS and SVLOPS 
development sites will have C170*s dedicated to C180 development 
running the same set of tools under NOS170. These systems will 
be stabilized versions of NOS 170. 

The C180 Develooment Support System* OSS18Q* will be the 
central tools agency to deve'top major toots and to ensure 
commonality and stability of the tools at the development sites* 
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All tools will be Interactively oriented as well as usable In 
batch mode. The tools will be structured as an Integrated 
system* providing simple and fast primitives usable In 
combination. System building/checkout capabilities h{|| 
emphasize binary module replacement and Incremental » continuing 
software integration. 

The standard mode of release of software Is binary code. C180 
development tools and CPU system source code will be available to 
customers as an extra cost option. 

The great majority of C180 system program* ing* Including 
tools* wilt be develooed In high level language* hence the tools 
requirements Include language processors and subordinate tpols. 

The anticipated heavy dependence on C170 systems for the bulk 
of C180 development makes It very Important that the ma|or OSS130 
tools be of releasable quality. In particular* they should 
support the CYBER 180 System Interface Standard and System 
Comirand Language interfaces and should track the NOS/180 co^rrand 
and program interfaces. Th Is .Incl udes suooortlng files In full 
8-blt ASCII. All new tools should be writtan In PASCAL-X for the 
170 f and designed and coded to transport with minimum effort to 
the CYBER 1«0. 



Testing of CYBER 180 software will Involve 
automated testing aids which are also part 
requirements. 



5.2.1 LANGUAGE PROCESSORS 



heavy use of 
of the tools 



fisafical 



a) Higher level languages will be used for CYBER 170/180 
system programming. 

II Products designed for release only on CY8ER 180 will be 
written In PASCAL Extended. 

2) Products designed for release on CYBER 170 will use 
SYMPL. 

31 Products designed for release on both 170 and 180 will 
use SYMPL. 

M Subject to AOiC approval* compilers and their object 
time routines m3y be written in their own languaqe* 
where there Is a significant cost advantage to do so. 
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5.0 SYSTEM ENGINEERING 
5.2.2*2 External 



b> The need for assemblers is acknowledged. In practice 
initial Implementation will be in higher level languages. 
When tuning* critical modules will be redesigned for the 
assembler as dictated by performance and hardware 
considerations. Because of severe memory constraints of 
the CYBER 170* CYBER 170 state codes usually resident in 
central memory will be done in assembly language. 

cl PPU code will be done in assembly language. CYBER 150 PPU 
source code will not be released to the field. 



fcnyJxeamaut 

Close coordination with tools subsystems is mandatory* with 
special emphasis ont 

at Coexistence with the source code maintenance subsystem. 

bl Separate specification of frequently used declarations for 
centralized control and flexible access by PASCAL Extended 
and Assembler modules with minor degradation In compile 
speed. 

c) Assembler Linkage 

- Definition in the System Interface Standard. 

- Minimum overhead linkage. 



5.2.2 ASSEMBLERS 



5.2.2.1 InJLfltQai 

The source code for CPU microcode or PPM and Basic operating 
system and diagnostic code 1180 state onlyl will not be 
rel eased. 

Microcode assemblers are controlled, documented and rralntalned 
by the responsible engineering development division. They are 
not to be released. 

The Internal PPU assembler is an extension of the C170 COMPASS 
PPU assembler* 
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5.2.2.2 External, 



There will be one external assembly language definition and 
implementation for the CYBER 180 CPU and IOU. The CPU oortlon 
must accept PASCAL-X variable* type and constant declarations. 



5.2.3 LIBRARY SUPPORT AND CONTROL 



In general* existing CYBER 170 products will be used as the 
design base tor these packages. Transition plans will be 
prepared for each* showing additions and deletions necsssary to 
ooerate In an Interactive/batch environment and to meet the CYBER 
180 System Interface Standard. 

The product capabilities listed below 3re a minimum set. They 
are In priority order with regard to the importance of providing 
a compatible bridge between CYBER 170 and CYBER 1801 

al One source code maintenance oackage compatible to UPDATE 
in . that it can create 180 PL's from 170 PL's* and a 
utility to generate a 170 PL including foldinq B-bit 
characters to 6 bits. 

b) "Common deck" capability - available for both source cbde 
and Job deck maintenance. 

c) Object code library maintenance package capable of 
handling code produced by any of the language processors* 
based on LIBEOIT. 

d) Job Deck Maintenance - dynamic modification and selective 
execution of Jobs for use In libraries of test and system 
generation Jobs* similar to OEVOUR and Included In al* 
above. 

t) Modification Change Control* similar to the Production 
Control System (PCS)* to include modules* histories of 
change rate. 



5.2.4 OTHER SUPPORT PACKAGES 



a) Documentation facilities 
usabil Ity. 



TEXTFORM with Improved 
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b) Produce global cross reference listings for the OS and 
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5.0 SYSTEM ENGINEERING 
5.2.6 EXTERNAL DISTRIBUTION 



Product Sett to Include data Items* module names* and 
error messages for PASCAL-X* SYMPL and the assembler. 

c) Simulate the CYBER 180 as_a_S*SlfiJE* with a simulated to 
real Instruction performance ratio of 1000 to 1. 

d) Simulate the CYBER 180 CPU with soft simulation of OS I/O 
requests* 

el A fast file transfer capability for 8-blt or binary 
Information via communications line between the ARHOPS and 
SVLOPS development systems. 

fl A form of channel coupled link between the* ARHOPS 
development CYBER 170 and the checkout CYBER 180. 

gl Symbolic .Interactive debugger for PASCAL-X and Assembly 
language. 



5.2.5 TEST BASE DEVELOPMENT 



al Standards and automated result checking routines for 
positive and negative testing. 

bl Support the requirement that test case definition be an 
Integral part of a test* and that tests are characterized 
and Indexed for automated retrieval. 

c> A stimulator will be required to simulate Interactive 
usage and remote batch traffic In order to test the 
communications capabilities of the total system. 

d> O.S* performance kernels to allow repetitive and weighted 
verification of O.S. Instruction allocations* 

e) RMS I/O performance kernels to test streaming rates and 
average random access rates. 

t) Utilities to monitor code coverage during test base 
execution* 



5.2*6 EXTERNAL DISTRIBUTION 



The following CYBER 180 tools <at least! will be available as 
Central Enhancement and Maintenance Services (CEMS) products In 
CYBER 180 mode* 
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SYMPL 

PASCAL-X 

ASSEMBLER 

UPDATE 

LIBEDIT 



••Cross-products* (executing on C170* producing code for C180) 
will not be released without exollclt permission from AOiC. 
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6.0 PRODUCT PHASING OBJECTIVES!* ) 



6.o pgooucT PHmuajaMEamESLiuL 



It Is a design objective to accommodate a phased 
i«ro f eraentatlon and release of selected products. functions, and 
features consistent with the malor design objectives identified 
In Section 1.3. 

The first release of the Network Operating System for CYBER 
180 (NOS/180) will have limited features and will be provided to 
selected customers. The major orientation of this release will 
be towards supporting mixed CY170/CY180 Job stream processing and 
providing the first set of conversion aids. NOS/180 Release 1 
(Rl) will provide a limited production capability? production or 
operations in the NOS/180 Rl timeframe is expected to be 
performed in CY170 mode with NOS/170 or NOS-BE. 

NOS/180 Release 2 CR2I will provide a production environment 
while continuing the emphasis on migration and conversion aids 
(particularly for NOS/BE 170?. NOS/180 R2 will be a complete 
release within the schedule constraints. Only seldomly used 
oroductst functions or features will ba deferred. NOS/180 
Release 3 will be a complete and competitive release* The 
following provides an overview of product phasing by major 
program elements! 

Notes! II C170 Indicates a capability provided by C170 
software and used by the 180 system. 
21 A single X indicates full capability with normal 

enhancements In later releases 
31 Multiple X Indicates phasing of the capability. 
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7.0 ££R££SMN£L_QfUEJILI)£E:S. 



The CYBER 180 architecture must allow the largest 
cost/performance range possible between the smallest model and 
the largest model • The range must be covered continuously with 
no cost and/or performance gaps within the line. 

Identifiable processor models must occur at performance level 
ratios of 3 !♦/- 0.51. At each level* a minimum starter system 
must be configurable with growth through add-on and/or 
replacement of hardware modules to allow the user to grow In 
smaller steps than total system replacement. 

The actual code sequences to be used In measuring performance 
are specified In the Environments I Workload Specification <see 
section 2.0)» along with the source language kernels and the 
various benchmarks used to establish the performance objectives. 



7.1 SI5IEii^REflBMUaL.&QALSl 



based on the target 



System performance objectives are 
configurations described In Appendix 0. 

System elapsed time is a function of the number of disks and 
the 0/S utilization of the disks. System elapsed time ratios 
ICY8ER-73/CYBER-180I are statedt based on the target 
configurations In Appendix D# to establish objectives for the 
0/S. 
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I 



TBF 



I TBL 



3500 

730 

29<*5 



I I 
I I 
11.21 
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TBF 



I 



TBF I iat 



(II CYOER-73 timings are In seconds* and are based on NOS 1.1 
«i30/t»28 (8/76)t and assume a 9GZ CPU utilization. 

(2) Multiple copies of the benchmark are reaulred to achieve 
these ratios - at least 9 for S3* and at least 20 for 
THETA. 

C3) CYBER 180 ratios are based on target configurations. 

(<•) To achieve a ratio of 18i 1 at least 30 disks are required 
and multiple copies of the benchmark must be run. 
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7*0 PERFORMANCE OBJECTIVES 
7.2 PRGCESSOR PERFORMANCE 



7.2 


EEXH££&^E£REQRI1AH£E 
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o suooort the System Performance Goats 


above* processors must 
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meet 


performance goals at the relative speeds listed 


below. 
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29 
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performance relative to 
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the memory and cache 


31 
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7.0 PERFORMANCE OBJECTIVES 
7.2.1 MEMORY ASSUMPTIONS 



7.2.1 MEMORY ASSUMPTIONS 



- Central memory access time ( A) including cables and 
bandwidth (Bl as defined belowi 



1 Memory 
Processor 1 Access Time 


(A) 


Memory 
1 Bandwidth (3) 


PI 


750 ns 




6V HB/s 


P2 


8<«0 ns 




6H MB/s 


P3 


616 ns 




128 M3/S 


THETA 1 


N/A 




N/A 



No conflict in central memory. 



7.2.2 CACHE ASSUMPTIONS 



PROCESSOR 


1 CACHE OATA 

HIT RATE 
1 (C) 


1 CACHE INST. 

HIT RATE 
1 (I) 


1 
1 

1 
1 


CACHE 
SIZE 


MAP HIT 
1 RATE (HI 


PI 




- 


1 
1 

1 
1 
1 


No 
Cache 


0.98 


P2 


0.75 


0.92 


16KB 


0.98 


P3 


0.82 


0.95 


1 

1 
1 


32KB 


0.99 


THETA 1 


0.82 


0.95 


32KB 


1 0.995 



Where 1KB=102*» bytes and Ct I and M are defined so that* 

• (1-C) of data words accesses shall require a central memory 
reference. 

- (1-1) of the Instructions (not Instruction words! shall 
require a central memory reference. 

- (1-M) of the process virtual address to real merrory address 

COMPANY PRIVATE ORAFT 
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7.Q PERFORMANCE OBJECTIVES 
7.2. 2 CACHE ASSUMPTIONS 



translations shall require central memory reference 
segment and page table information. 



for 



The cache sizes shown are recommended* Trade-offs between cache 
size and processor design can be made within the constraints of 
manufacturing cost and processor performance. 



Hit rates higher than 
estimating CPU performance. 



shown should not be assumed when 



7.2.3 BLOCK COPY PERFORMANCE 



The transfer rate for the Central Memory Block Copy 
Instructions (soft ECS feature) shall be at least on^ word every 
other clock cycle assuming no conflicts- CNalor cycle for P3I 
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7.0 PERFORMANCE OBJECTIVES 
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1 1 




7.3 MEMORY PERFORMANCE 










7.3 !JEMfl£I_EF.S&QRMN£E 
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7.3.1 CENTRAL MEMORY 








V 

5 
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To support the system performance 


goals abovet central memory 


r 
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must perform the requirements listed 


below. 
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1 1 
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1 1 SI 
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S2 


S3 1 THETA 1 


13 


1 1 
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lu 
15 
16 


1 1 
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IMaxlmum Memory 1 


1 






IT 


ICap3clty ! 


1 






11 


1-slngle CPU systeml 8 MB 


1 


8 MB 


16 MB 1 16 HO 1 


H 


l-dual CPU system 1 8 MB 


1 


16 MB 


32 M-.K1I 16 MB 1 


2G 


1 1 


1 






21 
22 

23 


1 1 


I 






IMaxirrum Total 1 6V M3/sl 


6V H9/s 


128 MB/sl 1000 *3/s % -1 


2«. 


IMemory Bandwidth 1 


1 






25 


1 1 


1 






2b 
27 
28 


1 t 


1 






INo conflict CPU 1 


1 






29 


lAccess Time (2) 1 
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1 No objective 1 


30 


1 1 


1 






31 


1-slngle CPU systeml 600 ns 
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728 ns 


1 616 ns 1 1 


32 


!-dual CPU system I 750 ns 


1 


78V ns 


1 672 ns 1 1 


33 


1 I 
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3V 

35 
36 


1 1 
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INo conflict 1 600 ns 


1 


896 ns 


1 896 ns 1 896 ns 1 


37 


1I0U Access Time 1 


1 






38 


1(2) 1 
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f «•«.« M« -«.■..«...■•«».•.•-».» f «.•_«.....«.. 


m ¥' 














V2 


(1) Not required until 


January 1 


, 1983. 


V3 










vv 


(2) All access times 


are measured at the memory ports. 


V5 


Additional delay may 


have to 


be added for calculations of 


vs 


CPU or IOU access. 


For 


dual-CPU configurations* the 


i*T 


access times are the 


average 


of two CPU's. 
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7.0 PERFORMANCE OBJECTIVES 
7.<f.l MONITORING/TUNING 



7.3.2 DUAL MAINFRAME SHAREO MEMORY 



The maximum total memory bandwidth between the central 
processor and a shared memory Is hi M3/s Cone 6*»-bit word every 
192 ns). This Is applicable to all systems fsee section 
3.1. !•<•). 



7.3.3 CONFIGURATION AND ENVIRONMENT MONITOR CCEMI 



The CEM reports power faults within one-half cycle of their 
occurrence! and responds to all other environmental faults In 

10ms. 

Digital sensors activate In resoonse to threshold crossings or 
pulsed Inputs within 5 ms. The transmission rate Is at least 
<t80Q bits/second. 

The level of electromagnetic Interference introduced as a 
result of sensing either within a monitored unit or transmitted 
from It, Is insignificant. The CEM and sensors must meet CDC EMC 
standards. 



r.h I2EEMUJiG_ilSiE!LEER£QStl&HCE 



7.V.I MONITORING/TUNING 



Mechanisms supporting measuring of ooeratlng system and 
general software performance and usage characteristics will be 
provided. Basic analysis tools for presenting this data In 
meaningful terms are to be Included. Measurement tools and 
services may be optionally selected. 

Capabilities for system tuning at system generation system 
load and execution times will be provided. Include tuning 
options to maximize performance In the following areas! 
• transaction 

- batch, local/remote 

- time sharing 

The level of performance achievable In any particular area is 
not required to be at the level of specifically developed 
dedicated application systems. 'The standard CYBER 180 operating 
system must be able to supply the majority of code that would 
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«ake up such dedicated special systems. 



7.«».2 IOU PERFORMANCE 



The CYBER 180 must provide a highly efficient I/O capability 
In both multi-programming and mono-orogrammlng modes. The I/O 
Unit provides! 

- Maximum burst transfer rate to central memory 

- 32 megabytes/second for II IS1I 

- 50 megabytes/second for 12 (S2, S3, THET Al 

- Device transfer rateSt both burst and sustained* not 
limited by I/O system fwlthln bandwidth limits!. 

- Ability to allow consecutive I/O requests to the sa*e 
device to be processed as If they Hera a single request* so 
as to eliminate a time oenalty of seoarate accesses. This 
is called "lata streaming" and requires that the 
consecutive requests be over|30Ded such that successor 
requests occur before the conoletlon of current requests. 

- Ability to allow 9-13 concurrent I/O transfers t9 dual PP 
transfers, 18 single PP transfers, or combinations 
thereof) • 

- CYBER 180 external channel transfer speed of 5 
megabytes/second. 

- PPU major cycle time, Ii-500ns.J I.2-250ns 
• PPU minor cycle time, 50ns. 



7.«*.3 OS WORKLOADS 



The following workloads must be able to run on a minimum 
conf lgurationt 

Dedicated Batch Mode - Minimum of 3 concurrent jobs fl 
compilation and 2 production Jobs* BDP oriented! 

On-line/Batch Mode • One on-line transaction application 
with ud to 35 terminals* mixed types with a throughout of 
3 to *t transactions per' second. (For measurement 
purposes* a transaction is an externally generated 
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7«<f •<»• i Record Manager 



INPUT/PROCESS/OUTPUT sequence requiring no more than 6 to 
8 accesses to RMS during processing.) Two batch .Jobs II 
compilation and 1 production J'obt BOP oriented). 

Oedlcated On-fine Mode - One on-line transaction 
application with uo to 100 termlnals# mixed types f OMS180 
access, with a throughput of 6 transactions per second. 



7.4.4 O/S INSTRUCTION ALLOCATION 



Performance objectives for specific functions Hlthln NOS/180 
are established below. Achievement of these objectives is 
•necessary for the overall system performance goals established In 
section 7.1. 

These Instruction counts will be superceded by 0,S* 
performance Kernels which incorporate the allocations* but allow 
design trade-offs to achieve the objectives. 

These allocations represent the number of machine instructions 
executed In the normal processing path associated with the 
requests. Error handling and other exception processing Is not 
Included* The counts are In terms of CYBER 180 Instructions* If 
used, the 115, 116, or 117 Instruction counts as 20 Instructions 
each and the use of exchange shall count as 40 each* 



7.4*4.1 RficjacjiJiajDjiaex 



The 
bel owl 



Instruction allocations for the Record Manager are given 



Record in Buffer 
Get/Put Sequential 
Get/Put Random byte address 
Get/Put Key 

Record not in Buffer (Physical I/O 

Manager not included) 
Get/Put Sequential 
Get/Put Random byte address 
Get/Put Key (index In buffer) 
Get/Put Key (index not In buffer) 



Instruction Count 

< 220 

< 320 

< 1000 



< 520 

< 620 

< 1800 

< 2500 



This includes the epilog and prolog of the record manager 
procedure. If any other procedures are called, the set up. 
call and execution of the called procedures must be 
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Included. 

These Instruction counts are Independent of record and block 
length having been based on a range of these parameters in both 
scientific and commercial environments*, 

7.4.4.2 Ej^sica! I/O riactagflc 



The instruction allocation for the Physical I/O Manager Is 
given belowt 

Instruction Count 

< 550 

< 4oo 



Generate PP request 
Request Completion 



This Includes the epilog and prolog of the Physical I/O 
Manager. If other procedures are called, their total 
Instruction count must be included. 

7.4.4.3 Task-Switching 

The instruction count for task switching upon suspension of a 
task due to I/O, time slice, etc. shall bet 



Task Switching 



Instruction Count 
< 500 



This includes the Instruction necessary to suspend a task» 
perform needed accounting for the suspended task, select a 
new task from a ready list, etc. A maximum of four (41 
exchanges are permitted, in addition to the instruction count 
given above* 



7.4.4.4 Batcfr Jpb 



}t} a nd Termination (Norm al Case) 



The maximum instruction count for Initiating or terminating a 
batch Job shal I bel 



Initiation or Termination 



Instruction Count 
<25000 



The maximum number of disk accesses (excluding paging) for 
initiation and termination shall bet 
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Disk Accesses 

«» 

1 



Initiation 
*?ead 
Write 

Termination 
Read 
Write 

/•<!.«• -5 Easia^Eajitt Handling 



The instruction allocation for handling a cage fault Is given 
belovtt 

Instruction Count 

< <»Q0 

< 500 



Page Available 

Page on Mass Storage (Physical 
I/O Manager not Included! 



This includes all instructions needed to process a page 
fault, 

7. *♦•*•• 6 Periodic Function 

In total these shall not consume more than 2»5% of the total 
CPU resoupce» as detailed belowl 



- Page Aging 

- Task scheduling - priority changing 

- Error monitoring Isee section 7.61 

- All other periodic functions 

7 •<♦.«♦. 7 Jak-Siia&CLLaa 



0.5% 
0.5% 
0.5% 
1.0% 



The rate of swapping shall be a variable parameter. The CYBER 
180 Instructions used shall not exceed 5000. 

7. «♦.*♦. 8 Laastec 



The table below states the loader requirements-. 

CPU TIME 
Processor Ratio to CY73 Benchmarks 

COMPANY PRIVATE ORAFT 
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PI 
P2 
P3 

THETA 



1.3 
2.8 

6.6 
32.0 



SBL.CBL and OMC80 
SBUCBL and BMC80 
SBL.CBL and 3MC80 
SBL,CBL and BMC60 



7 •«♦.«». 9 flualJState,..PeT.tarjn3.Q&£ 



Throughput using an SBL workload (see section 3*3-10 for 
conf Igurat Ions) t 



X170 


%180 


Elapsed Time 


100 





. 1.0 


70 


30 


1.0H 



30 



70 



1.08 



100 1.12 • 

Interstate Communication 

The CPU overhead per request for lnter-state comwunlcat Ion 
In dual state mode must not exceed the CPU overhead 
associated with the NOS/170 symmetric link MMF Interface In 
either an Idle or active status* 
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7.%.*. 10. 2 CPU UTILIZATION 

The table below indicates the percentage of CPU time to be 
utilized by NAM and BF to support 112 communication lines 
configured as followsi 

-12 are synchronous 2000-56#000 bps lines used for batch 
Input/output averaging 9600 bps/tlne. 

-100 are asynchronous 110-9600 bps lines used for Interactive 
applications averaging 600 bps/line. 

The CPU time used by NAM and BF is dependent on the sustained 
data transfer rate. 
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1 (11.2KB/ 


sec 


NAM CPU 
total 9 


X 

112 


term 


ina 


Is) 


9F CPU X 
(10.2KB/secl 


SI 








5.2Z 








* 1 

1 3.3* 


S2 








3,5* 










1.8Z 


S3 








2.5X 










0.8Z 


THETA 








2.2* 










0.6?. 



7. U.U. 10. 3 MEMORY UTILIZATION 



t 



The amount of real memory required by NAM and 9F to support 
112 communication lines configured with two 2550 Drocessors shall 
bei 

NAM 90K Bytes 

8F 30K Bytes 

7.5 feaCUCI SEI-.££gEjQSMLia£ 



7.5.1 LANGUAGE PERFORMANCE LEVELS 



The following table indicates • the language processor 
performance objectives. It specifies the performance values to 
be achieved (compile rate and disk accesses) when running the 
indicated benchmark at the indicated memory a! location. 

Where two levels of compilation performance are specified in 
the table below t they are defined as followsi 

OEV - Development mode* Characterized by extensive 
diagnostics and fast comollation rate at the expense of 
object code efficiency. 

PROD - Production mode. Characterized by highly efficient 
object code (soace/speedl generated at the expense of 
compl latlon rates. 
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7.0 PERFORMANCE OBJECTIVES 

7.5.1 LANGUAGE PERFORMANCE LEVELS 
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7.0 PERFORMANCE OBJECTIVES 

7.5.1 LANGUAGE PERFORMANCE LEVELS 



LANGUAGE PROCESSORS PERFORMANCE OBJECTIVES (1) 



— — 

Product 


Y --< 

1 Real 
1 Memory 
Al locat Ion 
t (2) 


Minimum 
Statements 
1 Compiled 
Per CPU Mln (3) 


Max Imum 
1 Disk' Accesses 

Per CPU Sec 
1 Allowed (<«) 


Benchmark 
151 


ALGOL-60 


150KO 


5,100 


22 




ALGOL 5 
Test Bas« 


ALGOL-68 


1 TBF 


TBF 


TBF 






A PL 


100KB 


NA 


TBF 






ASSEMBLER 


150K8 * 


15,000 


1 25 




FCT 


BASIC 
PRCO 
DEV 


TBF 

100K8 1 


TBF 1 
20.000 1 


TBF 

25 




BASIC JOB 
1,2,3,4,5 


COBOL 


150K8 


5,700 


37 




C8L,BMC80 
* SIMBOP 


FORTRAN 
PROO 

<0PT=2) 
OEV(TS) 


1 150KB 
125KB 


7.000 

13,000 1 


56 
23 




SBL 

SBL 


PL/1 


TBF 


TBF 


TBF 






WIRTH 1 
PASCAL 


100K8 


30,000 


20 






PASCAL- 
Ext enced 

PROO 

OEV 


1 150KB 1 
125K8 1 


4,000 
10,000 


TBF 
TBF 




Compl !e 
1 itself 


SYMPL 
PROO 
OEV 


150KB 
1 125K8 


4,000 
10,000 


56 
23 




CORipl 1* 

1 Itself 



(1) Performance values are for P2? values for other 

processors (including disk accesses) are proportionate to 

the performance figures for PASCAL-X in the table in 
section 7,2. 
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C2-) Real memory allocation Is the amount of real memory, 
including buffers and table space, to be assigned the 
compiler In running the Indicated benchmarh when 
measuring compile rate and disk accesses. 

(3) Statements compiled oer CPU e minute do NOT include 
comments. The CPU time Includes O/S time durinq 
compi I at Ions. 

*4> Oisk accesses per CPU minute is a measure of the load, lo 
I/O requests, the compiler Is olaclng on the system. The 
value indicates the maximum number allowed when running 
the indicated benchmark at tha Indicated memory 
allocation* QisK accesses for paging are included. 

(5) If no benchmark is indicated, a "typical** program has 
>500 data names, >1000 statements. 

TBF - To be furnished In subseauent revisions 



7.5.2 COOE EFFICIENCY 



a) FORTRAN supplied run time and mathemat ica I- rout lnes 
execute at the following speed ratios! 

Processor Performance 



shall 



CYBER 73(1) PI 



FORTRAN Run Time 
Routines and Math 
Library 



1.0 1.3 
(1) NOS 1.1 430/428 (8/76) base 



P2 
3.2 



P3 



9.6 



THETA 



36.0 



b) FORTRAN and COBOL generated code shall be as efficient as 
or better than the code sequences given in the Environment 
and Workload Specification, ARH1858, for CPU kernels. 
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7.0 PERFORMANCE OBJECTIVES 1 1 1 






7.5.3 OMS180 






7.5.3 OMS180 




1 
2 


TGF 




3 

k 
5 
6 


7.5.<» SORT/MERGE PERFORMANCE 




7 

8 

9 

10 


Minimum , OlsK Access 




11 


Working Set Size Records Sorted Per CPU 




12 


Processor (K Bytes* Per CPU Min (1) Second €31 


B/M 


13 
I* 


PI 100 121 1.3 X CYBER 73 120*F 


T3F 


15 
16 


P2 Same *»."5 X CYBER 73 SOOT 


Same 


17 


P3 Same 12-2 X CYBER 73 1500»F 


Same 


18 


THETA Same 3«».7 X CYBER 73 «»500*F 


Same 


19 
20 
21 


(1) Same sort benchmarK between CYBER 7^ and PN In that 


the 


22 


same number of strings will be produced by the Internal 


23 


sort Dhase. This will be controlled by the amount of 


2<t 


memory dedicated to this ohase. The ratio aool les 


only 


25 


to the time In the sort code. 




26 
27 


(21 The lUnlmum shall not exceed the given value* 




28 
29 


131 F equals JLULlUaaJLi * llc.tualJS££;aCJJLLfiD3l£lL 




30 


(Actual WS) ( 100 > 




31 
32 
33 

3*i 
35 


/ 




36 
37 
39 
39 
%0 
«»1 
«»2 
UZ 

US 
%6 
U7 
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7.0 PERFORMANCE OBJECTIVES 
7.6 MAINTENANCE SOFTWARE 



7.6 mUUMIEMti£E-S OF T H AR£ 



- Error monitoring will not reduce system throughout by tore 
than 0.57.. 

- No single test will exceed 50000 lines of source code. . 

-The object code size of tests Is limited to 176K9 iraxlmum. 
end the working set size Is limited to 100K3 maximum. 

'- Initialization utilities will not exceed two minutes run 
time for the maximum configuration. 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY (RAH) 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY <RAM> 
8.1.1.3 Component Crlticality 



8.0 MLIAaiUIX^^MAIUfllUIX^till^tlgLlliTAI NA^ ILITY (RAMI 



8.1 IfERATINO-ftlJPLSUPPQRT COMQlUaMS 



The anticipated usage and maintenance of the systemtsl 
specified below describe the environment and assumptions used in 
predicting RAM performance parameter values* 



8.1.1 OPERATING CONDITIONS 
8.1.1.1 Qui£_EacJL0XS 



It has been assumed that all mainframe components are powered 
up 1Q0X of the time - that is 720 hours/month. For peripherals 
the reliability data (HTBII have been based on field 
observations, and therefore the duty factors encountered in the 
field have been assumed implicitly. 

8.1.1.2 laca&i,c.ojiixauciaiXfla 



The target configuration^! of the CYBER 180 Systems is as 
specified in Appendix D. 

8.1.1.3 £pjitt&QfcaijSclil£aiily. 

Processor cache and MAP can be bypassed (except Sit* 

Op to 25JC of central memory may be flawed by software 
techniques. 

There will be only one I/O Unit. It has been assumed that 
there will always be a spare PPt hence in a configuration of n 
PP* s only (n-1) are required for normal operation. 

Whenever a degradation occurs in the mainframe, the system 
throughput is expected to decrease. 

The following equipment has been configured redundantly. That 

COMPANY PRIVATE DRAFT 
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•is, it has been assumed that loss of 3 redundant equipment does 
not degrade system throughput. 

Cnly four of six removaole disk storage units are required for 
noriral operation. • 

The loss of a removable disk storage unit controller will not 
cause the system to fall. 

Only three of four or four of six tape drives are' required for 
noriral operation. 

The loss of a communications processor will not cause a system 
crash. 

A single controller failure does not cause a system down. For 
system mass storage devices, there are two mass storage 
controllers for every four spindles. 

The operating system requires a designated spindle on the 
system mass storage device. Of the remaining spindles if one Is 
lost the system does not crash. 



8.1.2 SUPPORT CONOITION STRATEGY SUMMARY 



The maintenance strategy is as defined in the reference 
documents noted In Section 2.0. 

Where redundant equipment Is provided Preventive Maintenance 
does not interfere with normal system operation. 

Preventive maintenance intervals will be optimized around MTBI 
and life-cycle maintenance cost. 



8.1.3 ASSOCIATED RAM REQUIREMENTS 



The reliability, availability and maintainability of the CYBER 
180 systems is derived from the RAM ofi 

.- the individual hardware elements 

- the Operating System software 

- the tests and diagnostics used to rralntain the hardware. 

Failure of any one of these components to meet its RAM objectives 
could compromise the system RAM.' It should be noted that the 
Operating System reliability objectives have been set 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY <RAN) 
8.1. 3* ASSOCIATED RAM REQUIREMENTS 
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8.0 RELIABILITY, AVAILABILITY ANO MAINTAINABILITY <RAM) 

8. 2.1 RELIABILITY FEATURES _ 



significantly higher than has ever been achieved for new software 
running on new hardware. 



8.2 JB4JOXAIMES 



The guidelines for total costs for RAM features for a given 
nalnfraree element will be 10-15X of hardware manufacturing cost 
except for the THETA CPU. The guideline for the THETA CPU RAM 
costs will be 32-157. of manufacturing cost, subject to the 
constraint that scientific performance is degraded by no more 
than 2%. 



8.2.1 RELIABILITY FEATURES 

Reliability features reduce failure rates of hardware and 
software, and minimize component faults from becoming equipment 
and system failures. Specifically, reliability Is defined as 
preventing the occurrence or propagation of errors. Reliability 
features will include! 

Parity checKlng on major data paths, address paths, 
channels, registers and memories except for fh9 THETA CPU, 
which shall include parity checKlng within restrictions 
listed in paragraph 8.2. 

- Error status registers. 

Time-out mechanisms to provide continuous operation of 
system facilities. 

- Methods of forcing conditions so that checks can be made 
of the reliability circuitry. 

Svf.tWJEfi 

A validation check of disk write positioning. 

- Checksum techniques for key system tables* 

- Except for offline diagnostics, validate a link using 
software checks fe.g., transferring data blocks and 
checksums) before actual data transmission. 

- Other checks by I/O drivers for malfunctions that are 

COMPANY PRIVATE ORAFT 



1 

Z 
3 
S 
5 
6 
7 
8 
9 
10 
11 
12 
13 
l<f 
15 
16 
17 
18 
19 
20 
21 
22 
23 
ZU 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3«i 
35 
36 
37 
38 
39 
%0 
hi 
hZ 
%3 

HS 
%6 
hi 

ta 

%9 
50 



characteristic of a device. 

JQlfli2£osJLL£S 

- The system Initialization process to include confidence 
level tests run against critical system corcponents- 

8.2.2 AVAILABILITY FEATURES 

Availability features are defined as those providing alternate 
paths around failing or failed system functional components to 
minimize impact on a running production system. Availability 
features will include* 

Hardware 

- Single error correction/double error detection (SEC/OEOI 
Implemented on central memory. 

- Hardware instruction retry providing the Instruction fails 
before destroying any information. 

* - Use of motor generator sets to decrease sensitivity to 
commercial power (2.5 second ride through). 

- Execution of user supplied data recovery algorithms after 
standard system error recovery procedures. 

- Checkpoint recovery facilities both at the individual |ob 
and at the system level, such that the environment may be 
re-established after a system failure. These facilities 
will apply to single and multi-mainframe environments. 

BacjgjHarj£^5ujaD.a.rJL£.d..bY . SailJiar.fi. 

- Capability to "fault" portions of the cache buffer and map 
buffer exceot on SI. 

- Capability to idle a PP in the IOU and assign another PP 
to perform its task. 

- Reconfiguration by a combination of hardware and software 
techniques following failures, automated as far as 
possible. 



JQUlflLSflflSJLLcJi 
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9.0 RELIABILITY* AVAILABILttY AND MAINTAINABILITY (RAH) 
6. 2.2 AVAILAnlLtTY FEATURES 
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8.0 RELtAtttLttY, AVAtLAdtLItY AND HA INTA INABILITY (DAM) 
8.2.3 MAINTAINABILITY FEATURES 



The ability to run diagnostics concurrently with customer 
operations to Isolate faults In one of dual processors* 
peripherals* peripheral controllers* and certain modes of 
failure In memory. 

Through the standard support* OOZ of the hardware problems 
associated with a second processor and peripherals will be 
repairable concurrent with system operations* 

Support of data Integrity by all maintenance software. In 
that this software shall never over write those areas of 
dlskt etc. while reserved for customer use. 

Support of deferred maintenance by the on-line monltor# 

Reduced repair time on system elements through the use of 
Isolation diagnostics and remote maintenance. 

Minimizing preventive maintenance on al I eauloments. The 
Engineering file analyzer will trigger maintenance actions 
based on usage and error rates. On new hardware being 
developed for CYBER 160 the objective should be minimum. 
preventive maintenance* 



8.2.3 MAINTAINABILITY FEATURES 



Maintainability features are Intended to optlrrlze the 
effectiveness of error Isolation and maintenance support. They 
wilt Include! 

- Error signals which localize faults. 

Microprogram control of CPU Instruction execution except 
for THETA. 

Minimize the number of mainframe module types with all 
like modules fully interchangeable. Mainframe modules 
will be reolaceaole when power Is on. but C.S. down. 

Privileged operational modes to execute maintenance 

service facilities. For example* vary clock pulse-width 

margins under program control, or vary voltage margins 
manual I y . 
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Logging of transient and permanent faults. Logging of 
operating system deadstart recovery and obtain 
supplemental Information statistical RAM Information from 
operator Initiated restarts. . , 

Relinaulsh all. but a minimum of system critical components 
to« concurrent maintenance as needed., while normal customer 
operation continues. 

Remote access to those facilities under off-line or 
on-line maintenance control which can be used for hardware 
and software maintenance. 



magngsll&s 



Oeslgn CYBER 180 Maintenance Software to allow hardware 
maintenance to be performed concurrent with customer 
operation. 



8.2.% MAINTENANCE SOFTWARE 



The performance objectives for CYBER 180 Level II end* III 
maintenance software are described In the following paragraohs- 



6.2 • «♦•! Q n-Lin e Monitor 



II fle "crash-proof " for at least 95* of all hardware and 

system software failures. 
2) Provide 100X adherence to OS requirements for security. 

file structures and resource access* 



6. 2. 4. 2 fllLlUttftJlaDJJLftC 



1! Provide I00X validation of all operator actions. 
8 . 2 . U . 3 l£5Ui._Qiaao&£ll££jL Jl tUlli£&_lfflalnir^mjL-flQiy_l 

II Tests 

- Shall detect 95X of all solid* software detectable 
failures* and 90X of the same failures wron run in their 
shortened versions as determined by default parameter 
selection. 

- Shall correctly Identify the functional area for at 
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5,0 RELIABILITY, AVAILABILITY ANO MAINTAINABILITY 1RAM) 
9.2.N.3 Tests* 0l3gnostlcst Utilities tmalnframe only) 
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8.0 RELIABILITY. AVAILABILITY AND MAINTAINABILITY (RAM) 
3.3 RAH SUPPORT COSTS 



least 907. of all failures detected. 

- Shall provide a detect ion capabi 1 1 ty which supports the 
MTTR goafs of the various products. 

- Provide 100X protection for all customers security and 
file structure requirements. 

21 Diagnostics 

- Shall isolate to three or less replaceable subassemblies 
for 9051 of all solid failures identified to a functional 
area. 

- Shall provide an isolation capability Hhlch supports the 
MTTR goals of the various products* 

- Provide 100Z protection for all customers security and 
file structure requirements. 

NOTEl The cost effectiveness of isolation diagnostics will be 
examined in detail prior to submission of OR*s. 

31 Utilities 

Al Engineering File Analysis 

- Shall provide 100X adherence to all OS requirements 
for security? file structure and resource access. 

- Shall provide an on-line analysis capability for 100X 
of all errors logged 

- Shall provide an off-line capability for fatal errors 
on system critical elements- 

Bl Maintenance Scheduler CCAMSI 

- Shall provide maintenance schedules for 1002 of all 
supported CYBER 180 equipment on each site. 

CI Initlallzatlon/Oeadstart Tests 

- Shall be capable of detecting 70X of all solid 
software detectable failures in the associated 
hardware. 
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'8.3 BAtf_S!!EPQSL_£QSLI£ 

8.3.1 FACTORY CONTINUATION COSTS 
5.3.1.1 Field Chan ge Or ders. 



FCO Hours/Equip/Year 

12M xz&t issiz iafti 13J& iaas jlm^ 



SI Mainframe 




75 


15 


23 


15 


8 


8 


P2 


75 


15 


23 


15 


8 


8 





M2 


10 


15 


10 


5 


5 








P3 




30 


35 


<*0 


30 


20 


10 


M3 




10 


15 


10 


5 


5 





THETA CPU 








20 


50 


HQ 


30 


THETA MEMORY 








3 


10 


15 


10 



I/O 



10 



15 



20 



Number of FCO*s/Eauip/Year (#11 
112JL 12ftl 12i2L 12&J 13J& 13*5 12&6 



SI Ma 


Inframe 




30 


6 


10 
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<t 
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P2 




30 • 
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10 
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H 





M2 




<* 
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P3 
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16 
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** 


M3 
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THETA 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY CRAM) 
8.3.1.2 Software Maintenance Costs 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY CRAM) 
8*3*2 FIELO MAINTENANCE COSTS 



8.3.1.2 Solt.Hac*..Halnt,floaQfift-£flSls 



The estimates below are software maintenance objectives for 
the first five-years following release. The following 
assumptions apply* 

- cost to fix one bug S500 except first year (vs. 1976 CYBER 
170 cost, of S675I. 

- distribution of bug reports to be «i5X operating system, 15% 
FORTRAN* 15% COBOL/SORT, 157. DNS180 and 10X other. 

- once released, only validated bug fixes are added to a 
software system* No PSR*s are accepted 3 years after 
release* 

- when t^9 next version software system Is released, current 
version users will convert at 501 per year* 



- Year 



X Shipped 
As CYBER 180 



1982 1983 198<« 1985 1986 
10 20 <tQ 80 ' 100 



X C170 10 

Mode Converting 
To C180 



20 



30 



«»0 



SO 



YEAR 



Cumul at Ive 
Member C180 
Systems 

"maintenance" 
cost in 
millions 

monthly 
receipt of 
error reports 



SOFTWARE MAINTENANCE COSTS 



I 1982 I 1983 t 198«» I 1985 I 1986 I 
.».*> -*- ♦ 4— — -♦ — — ♦ 

I 

I 

I 
233 I 

I 
1.7 I 

I 

I 

I 
290 I 

I 

I 



1 25 


95 1 


1 0.9 


1.1 1 


1 65 


185 1 
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8.3*2 FIELO MAINTENANCE COSTS 
8*3.2.1 tf acdjiaQe_!ialn^£aaD£^^ 

Emphasis will be placed on ease of installation including 
parameters such as.i 

1> Physical interconnectabl 1 1 1 v 
2) Environmental requirements 

to the end of reducing Installation costs* 

The monthly maintenance cost for CYBER 180 malnfrate systems 
(excluding peripheral equlpmentl Incurred by the supporting field 
Service organization must not exceed the follo«lng levels 
(expressed as a percentage of manufacturing costlt 



Life Cycle 

System Average Monthly 

Model Halci±fla3ac~£_£fls± 

51 0*67* 

52 0.537. 

53 0.537. 
THETA 0.45Z 



Second Year 
Monthly Maintenance 
Easl-JBkUctlve, 

0.85Z 
0.677. 
0.67X 
0.5«#t 
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"System model M Includes Drocessor,, memory and IOU. These 
costs Include both the direct cost of maintaining the eoulpment 
and the allocation of various Indirect costs, as followsi 

Direct Costs Include the following labor, travel and parts 
categoryl 

- Remedial Maintenance Labor 

- Preventive Maintenance Labor 

- Associated Repair Labor 

- Consumable Parts 

- Rework of Replaceable Modules 

- Travel Time and Expenses (for field service personnel) 

lBdJjCJ!cJL£P.Sl 

Indirect costs Include the allocation of the following expense 
COMPANY PRIVATE DRAFT 
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8.0 RELIABILITY. AVAILABILITY AND MAINTAINABILITY CRAM! 
8.3.2*1 Hardware Maintenance Costs - Mainframe Systeir 
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8.0 RELIABILITY. AVAILABILITY AND MAINTAINABILITY <RAM> • 
8.<i RAM PERFORMANCE OBJECTIVES 



categoriesi 



Training ffor field service personnel) 

Notei These costs are minimized by utilizing tools such 

as isolation diagnostics which will allow the use 

of MAL-B trained personnel. 
Tools and Test Equipment 

Notei These costs are minimized by utilizing tools such 

.as isolation diagnostics which eliminate the need 

for portable testers* 
Spare Parts Inventory 

Diagnostic Software Maintenance and Distribution 
Home Office Support 



8.% BAJtL£EfiEQSllAHII£^QJaaECIiy.ES. 

Values are specified for field release of first system? six 

months after release; and 18 months after release* Expected 

values for the hardware have been based on the growth curves 
established in reference 9. 

Fortulas used are as follows! 

Si. PZt IOU I MTBI - MT8F 10. 60-0*35 exp t-0.035TII 

M2 • MTBI = HT8F 10. 60-0.35 exp (-0.035TM 

M3 t MTBI = MTBF (0.60-0.«i0 exp C-0.035TH 

M«i I MTBI = MTBF CO. 60-0**5 exp t-0.035UI 

PS I MTBI = MTBF (0.60-0.<»5 exp C-0.02TM 

THETA I MTBI = MTBF CO.60-0.%5 exp <-0.02TM 

Hhert! 

MTBI Is the expected* observed MF8I 

MTBF is the Inherent MTBF 

and T is in months after release 

In addition* the expected values on release take into account 
the effect of degradabi I ity te.q.t cachet MAP bypass) as follows 

Expected MfBI = MTBI / P 

COMPANY PRIVATE DRAFT 
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Hhere P is the probability that a failure to a component in the 
equipment causes the equipment and system to fall. 

* 
Probability factors have been set as followsi 

SI - 60% 

P2 - 80% 

P3 - 70% 

THETA - 90-95% 

Memory - 75% 

IOU - 90-95% 

Finally* the affect of redundancy has been accommodated. This 
means that memory reliability includes the benefits of SECDEO. 
Although it is a requirement for the Operating System to degrade 
the IOU this is not factored into the objectives which follow. 

8.l».l MEAN TIME BETWEEN SYSTEM DOWN INTERRUPTIONS CMTBI O0WN1 

The operating system components are estimates based on the 
fol lowing assumptionst 

- The same basic software system is used throughout with only 
validated bug fixes added. 

- There is no radical change in the nature of the user's 
production workload. 

- The O.S. MTBI is inversely proportional to the square root 
of processor speed* 

- Automated restart features (defined to return system to 
productive state within 1 mlnutel effectively Increase the 
HTBI by a factor of 2* 

The objectives stated below ignore failures due to crown-outs 
and other power fluctuations* They indicate the factor of two 
derived from the automated restart feature of the. Operating 
Systeir. In all cases values are expected* observed values. 
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*NO MAINTAINABILITY IRAMI 




8.0 RELIABILITY, AVAILABILITY ANO MAINTAINABILITY (RAM) 






8.*.1 HEAN TIME BETWEEN SYSTEH 


OOMN INTERRUPTIONS (MIDI DOWN! 






1 
Z 


8.*.1 MEAN TIME BETWEEN SYSTEM DOWN INTERRUPTIONS (MTBI DOWN) 






















* 










......#. 


i 


f 








• 








1 


1 












2 


1MT8l(dn) (hrs) 


TARGET 


S 


1 S Y 


STEM 








t 


3 


INTBI(dn) (hrs) 


TARGET THETA 


SYS 


T E M 






3 




















* 

5 

6 


1 




■ 








* 

5 


IPOINT IN TIME 1 


CPU 1 MEMORY 




I/O IPERIPHSt 


O/S 1 


TOTAL 1 


TOTAL 


1 


IPOINT IN TIME 1 


CPU IMEMORY 1 I/O IPERIPHSI 


O/S 1 


TOTAL 1 


TOTAL 1 


6 


t 1 


1 






1 


1 


H/M 1 


SYS 


1 


7 


I 1 


1 1 1 


1. 


1 


H/W 1 


SYS 1 


7 




ton Release 1 


5551 -INC- 




-INC- 1 


30001 


5001 


*68l 


r k ° 

2*21 > 9 


lOn Release 1 


1911 **7! 9*21 


30001 


1001 


1131 


531 


• 9 










1 








1 


10 


1 1 


1 1 1 


1 


1 


1 




10 


ISlx Months 1 


6201 -INC- 




-INC- 1 


30001 


5001 


51*! 


2531 


11 


ISlx Months 1 


2221 5281 9781 


30001 


1001 


1291 


561 


11 


1 1 


1 






1 


1 


1 




1 


12 


I 1 


1 1 1 


1 


1 


1 




12 


118 Months 1 


7171 -INC- 




-INC- 1 


30001 


16001 


5781 


*25l 


13 


118 Months 1 


27*1 6*91 10291 


30001 


2671 


15*1 


98 1 


13 


t 1 


1 


.#.. 




1 

.... — ♦-. 


1 
*- 


I 




-• 


1* 
15 


1 1 


1 1 1 


1 


1 
... — -♦. 


1 


.......* 


I* 
15 


f ....... 
















t 


16 
17 


INC weans included In the CPU. 








1 


16 
17 


IMTOl(dn) (hrs) 


TARGET 


S 


2 ST 


STEM 








1 


16 














18 


1 
















1 


19 
20 
21 


8.*. 2 (#1) 


MEAN TIME BETWEEN SYSTEM 


DEGRAUEO INTERRUPTIONS 




19 

?n 




CPU 1 MEMORY 


1 


I/O IPERIPHSI 


O/S 1 


TOTAL 1 


TOTAL 


1 












.......+ 


21 


IPOINT IN TIME 1 


♦•---——--- -——«••--« 














t t 


1 


1 


1 


1 


1 


H/W 1 


SYS 


1 


22 


1 












22 










. 








»♦ 


23 


IHTBI(dg) (hrs) 


TARGET .SI SY 


STEM 








r\l 




















lOn Release • 1 
t 1 
ISitf Months 1 


10101 10171 

1 1 

10751 10831 


13%7I 

1 

1*331 


30001 

1 

30001 


3001 

1 

3001 


3281 


1571 


2* 
25 
26 


1 












2* 
25 


I 
3*71 


I 
1611 


•f--— —-—-—— ------ 

IPOINT IN TIME 1 


CPU IMEMORY 1 I/O IPERIPHSI 


O/S 1 


TOTAL I 


TOTAL 1 


26 


1 1 

118* Months I 
1 I 


1 


1 


1 

15591 

1 


1 

30001 
1 


1 

9001 

1 


. 1 

3731 

1 




I 


27 
28 
29 
30 
31 


1 1 


1 1 1 


1 


t 


H/W I 

....... f.. 


SYS 1 


27 

28 


1 I 


1 


lOn Release 1 


8331 -INC- 1 -INC- 1 
III 


90001 

1 

9000 1 


151 


7511 


151 


29 








»- 


~ 


* 


*"" 






ISlx Months 1 
1 1 


9301 -INC- 1 -INC- 1 
1 1 I 


151 


8291 


151 


M 


! 
















1 


1 


I 


1 




32 


IMTBKdn) (hrs) 


TARGET 


s 


3 S Y 


STEM 








1 


33 


118 Months 1 


10751 -INC- 1 -INC- 1 


90001 


*91 


9*21 


*7I 


33 


1 
















1 


3* 
35 

36 


1 1 


1 1 I 


1 


1 


1 


....... t 


3* 
T5 


IPOINT IN TIME t 


CPU 1MEMORY 


-f- 

1 


I/O IPERIPHSI 


»— — —— — ♦- 
O/S 1 


— ————-♦-> 
TOTAL 1 


TOTAL 


1 














36 


1 1 


I 


1 


1 


1 


1 


H/W 1 


SYS 


1 


37 
38 
39 














51 
18 


lOn Release 1 


6331 6071 


121%l 


30001 


1671 


2281 


961 














39 


1 1 


1 


1 


1 


1 


1 


1 




1 


*0 














*0 


ISix Months 1 


7361 6961 


12921 


30001 


1671 


2561 


1011 


ut 














*1 






1 




1 








1 


*2 














*2 


118 Months 1 


9071 8281 


1*061 


30001 


5331 


2981 


1911 


*3 














*3 






! 




I 








1 


** 
*5 
<i6 














** 
<»5 
































<*6 




















*7 














*7 




















W 














*0 




















*9 














<»9 




















50 














50 



COMPANY PRIVATE 



DRAFT 



COMPANY PRIVATE 



DRAFT 



0-15 

06/06/re 
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8.0 REtlABItlTYt AVAILABILITY AND MAINTAINABILITY (RAMI 
8.4,3 MEAN LOST TIME DUE TO SYSTEM DOWN INTERRUPTIONS 
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INC means Included In the CPU. 
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8.4.3 MEAN LOST TIME DUE TO SYSTEM DOWN INTERRUPTIONS 



Mean lost time is defined In units of minutes oer failure* 
Objectives for Sl-THETA systems are shown In the fol toning 
tables! 
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8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY (RAM) 

8.«»o* Cfl) MEAN LOST TIME DUE TO SYSTEM OEGRADED INTERRUPTIONS 
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8.<».<f (#1) MEAN LOST TIME DUE TO SYSTEM OEGRAOED INTERRUPTIONS 



The objectives in this araa are based on the following 
assumptions! 

1) When a degraded interruption occurs* the |ob which was in 
execution at the tine of the Interruption is aborted. 

2) The system throughput in degraded mo.de is 50X of the 
norma! system throughput for all system degradations* 

3) A Customer Engineer is contacted Immediately to correct 
the problem. 
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8.0 RELIABILITY* AVAILABILITY AND MAINTAINABILITY <RAM) 
8.*. 7 NET AVAILABILITY 



1 

IMLTIdg) trelnsl 

I 



TARGET 



S 3 



SYS T € M 



JPOINT IN TIME 1 


CPU IMEMORY 1 


I/O IPERIPHSI 


O/S 


1 


TOTAL 1 


TOTAL 


t I 


1 


I 


1 


1 




1 


H/H J 


SYS 


lOn Release 1 


90 t 


roi 


831 


1051 




%l 


831 


5 


1 1 


1 


t 


1 


1 




1 


1 




ISlx Months t 
1 f 


901 

1 


701 

I 


83! 
I 


1051 
t 




%l 
1 


831 

1 


5 


118 Months 1 


831 


681 


78 t 


1051 




%l 


791 


5 


S 1 


f 


1 


1 


1 




1 


1 





INC means Included In the CPU. 



8*%. 5 DATA ERROR RATES 



Data error rates are dominated by peripheral data error rates on all 
systems* The objectives stated below apply to Si through THETA systems 
on release* six months and 18 months atter release* This data shall be 
measured at the user I/O interface* 

a) Rfi<:fii?sscaiLLfl_dala->flccacs 

The recoverable data error rata shall be one error per 10**9 
bits of correct data* 

b> UD£SCj^exatUs^da±a_£CXOXS 

The unrecoverable data error rate shall be one error per 10**11 
bits of correct data* 

c> Ui!iJ^l££lfid«dal3L-£rxflcs 

The undetected data error rate shall be less than one error per 
10»*16 bits of correct data. 



8.%*6 USER AVAILABILITY 



The user availability includes all items listed under net 
availability below* except preventive maintenance time which does not 
form oart of the scheduled operating time* User availability of all 
systems at release and thereafter shall exceed 99X* 
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»*%.7 NET AVAILABILITY 



The objectives JLoslydfit ■ 

- the time taKen for an engineer to get to the site to repair the 
failure* 

- the time taKen to effect the repair (HTTRI. 

- the time taKen to restore the system to its original 
state dQOl re-run time necessitated by the failure* W*lohted 
rerun times are used in the calculations* based on the falling 
equipment type. 

- time taKen on preventive maintenance* assuming this is conducted 
by a single engineer* 

• tlwe lost due to degraded interruptions. 
The objectives axe fude t 

t tiire to raaKe changes to the hardware CFCO'sl* 

- time to make changes to the software CPSR'sl* 

• the affect of on-line maintenance software failures on the 
overal I system. 

4. • . .... • 1- 

I I 

I SYSTEM AVAILABILITY OBJECTIVES - CYBER 180 I 
I I 
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8.0 RELIABILITY* AYAILAOILITY AND MAINTAINABILITY CRAM) 
6.5.3 FAILURE RATES 



8.5 MItLI£lsAliJC£JSLQ£IHlS£^SAtLEASi!3EIESSL 



8.5.1 RAM PERFORMANCE PARAMETERS (LEVEL III1 



The following RAM parameters for Level III maintenance software are 
based on a duty factor of IX fop the diagnostics. For example* if the 
diagnostics were run continuously then or>ce every 175 hours they would 
cause a system down Interruption at release. However* based on the 
typical field usage (IX duty factor! system down Interruptions should 
not occur more frequently than every 17,500 hours. 

* . .. f — . . «. ...*. — * 

IParameter .1 Release !6mo. After USmo.Afterl 
I I I Release I Release I 

*.. f ... * — . ..|. — — §, 

IMT8I Down I 175 hrs f 200 hrs I 250 hrs I 

* f . .4. . — ...... — . — «. 

1MTBI Degraded! 125 hrs I l«i2 hrs I 175 hrs I 
!(#I> I I I I 

♦ — ; ♦ .. f — . . — f . «. 

IMLT Down I 0.6 hrs I 0.6 hrs I 0.6 hrs I 

f_. * 1 .. 4.. — . . — 4. — — §. 

IHLT Degraded I 0.8 hrs I 0.8 hrs I 0.8 hrs I 
Mil) I II I 

t 4... .„* .. f * 

1A CU) I 99. IX I 99. 2X I 99. 3X I 

4 . f .. — . 4. . 4.-..- ...„-«. 



8.5.2 UPOATE AND INSTALLATION 



Maintenance Software components shall be designed and constructed 

to permit library maintenance and update using standard system 

software and firmware. Hardware r%Q\jlred to support said maintenance 

shall be nriy standard configuration as stated In Appendix 0. 

It Is estimated that one (1) MAL C trained CE shall be able to 
Install or update the Maintenance Software Library In the following 
times! 



BELEASfi 6.8QS 



Install New System 
Update Id System 



2.0 hrs. 
1.0 hrs. 



Ii5 hrs 
.5 hrs 



ifU!QS*ZMSI 

1.0 hrs/$300 per year 
•2 hrs/$150 per year 
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8.5.3 FAILURE RATES 



fi£CJsljQ3-J2l_£JLL 

Critical OPSRs/PSRs 
Major DPSRs/PSRs 
Minor DPSRs/PSRs 
Inforiration OPSRs/PSRs 



Failure Rates/1000 |obs 



Sftltasa &-.MA5 10 .flflJS 





2 

17 

6 

25~" 

0.1X 



1 
2 
8 
5 

16" 



0.057. 0.0051 



Individual Objectives are as fol lowst 



DP3R«s/Mo 0PSR*s/Mo OPS9«s/Mo 

at_Raiaa&& ai_£_!iiu_ alJUUUu- 
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"is" 



0-5 
0.5 
1.0 
1.0 
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10.0 



0.6 EBflQIH2I_SEI_BaM_EASAllEIEa& 

Where applicable* product set members will support the RAM features 
described In COC System Standard 1.12.00U as specified In the CYBER 
180 System Interface Standard. 

8.6.1 PROOUCT FAILURE RATE 

A test base shall be established fo^ eich product representing 
customers* use of the product. The failure rate for each product 
against Its test base is given below In failures per 1000 unique Jobs 
run as measured In the internal system test ohase (excluding 
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8.0 RELIABILITY, AVAILABILITY 


ANO MAINTAINABILITY CRAM! 








8.6.1 PRODUCT FAILURE RATE 
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8.0 RELIABILITY, AVAILABILITY ANO MAINTAINABILITY CRAM) 
8.6.2 PRODUCT INPUT DATA FAILURE RATE CPIOFRI 



8.6.2 PRODUCT INPUT OATA FAILURE RATE CPIDFRI 



The PIOFR Is stated in terms of failures per million inputs 
processed. A failure is a Job abort and is measured in the live field 
environment. 
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8.6.2 PRODUCT INPUT DATA FAILURE RATE (PIOFRI 



8-26 

06/08/78 



8.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY (RAH) 
8.6.<» MAINTENANCE 



fr « functional requests 
rp = records processed. 



8.6.3 INSTALLA9ILITV 



Insta 1 1 abil ity features will emphasize! 

1) Slnpte field operating system installation sequence. 

21 Automated or semi automated configuration definition. 

No product shall reauire more than one hour preparation time to 
Install or replace (update) by a programmer analyst with 6 months 
experience and i »onth training on CYBER 180 hardware and software. 
In addition, no product shall require more than two minutes CPU time 
on an 52 system for its installation (assuming binary code 
distribution with adjustment for installation options has been 
accomplished prior to shipment). 
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8.6. «* MAINTENANCE 



The total number of PSR*s received per 
System and product set are shown belowt 



mflnth. for th« Operating 
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at 
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The nuirber , of critical PSR"s» (either backlog or monthly rate! 
shall not exceed 5X of the objectives stated above for any product. 
PSR*s are unique problems. Internally and externally generated* 
excluding informational errors. See Section 8.3.1.2 for costs* In 
addition, there shall be no backlog of critical *>SR*s at the time that 
the system/product enters Its final build, nor any unanswered critical 
PSR's at release. 
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5.0 RELIABILITY, AVAILABILITY AND MAINTAINABILITY IRAMI 
8.6.5 SUBSYSTEM RELIA3ILITY 



8.6.5 SUBSYSTEM RELIABILITY i 

A subsystem is a software service routine* not part of the basic 
Operating System, which Interfaces between multiple users or Jobs and 
CY9ER-18Q system resources. Some specific examoles are! 

Dual state link 

Mul tl-malnf rame 

Oata management systems 

. Network products. 

All subsystems must meet the following reliability goatst 

II Cannot cause NOS/180 to crash 

21 Cannot cause all users to reinltlal l*ei 

- due to subsystem failure at an interval less than three 

times the NOS/180 MTBt. 

- Mhen the subsystem drops or adds system resources I such as 

terminals, front ends, data bases* etc. - through a 
defined range of configurations !• 
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9.0 OBJECTIVES EXCLUOEO 



9.0 nfij£mmjE£Cj.imEJ2 



9.1 flfljErjiy^s^Pi^iElCALLY EXCLUD£a 



These objectives are not. and will not be included in the CYBER 180 
program as defined in this document. 

- Interface to IBM System Network Architecture. 

- Support for direct execution (emulationl of processors other 
than CYBER 1T0. 



9.2 njj E rj i y £S ^nj L . S ££CI£I£ALL3L.ESE£LUQ£Jl 



These objectives are not Included but could be included- in the 
CYBER 180 program as defined in this document. 

• Suoport of most compiler languages. 

- Implementation of a time-critical software operating mode Isee 
3.1.21. 

- Support of the STAR 100 system as a computational facility. 
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10*0 CYBER 170 STATE 



10.0 £U3£S_UaJiIAIE 



10.1 BAI!J£RAaE_EEAIiiRE& 

10.1.1 CURRENT CYBER 170 FEATURES SUPPORTED 

a) CYBER 173. CPU Instruction set 

- CMU instruction hardware detection 

- C176 instruction stack purging (norma II 

- C173 comoatible Instruction stack purging (selectable* 
with 35X CPU slow down) 

- CEJ/MEJ permanently enabled 

- C176 014, 015 instructions are supported 

bl 131K, 262K 60 bit words central memory fexcept THETA - 
524K. 1048KI 

cl Extended memory fnot supported on Sll 

- ECS (I and III 

- OOP model OC145 

- Extended Semiconductor memory In ECS Hode 

- High Speed Port Maintenance Functions an supported 
in off-line mode only 

- Side Ooor Maintenance access is supported on-line by 
NOS only to the extent of maintaining the ESM single 
bit error hardware logs 

d) 10x12, 15x24, 20x24 PP and Channel combinations 
el CYBER 170 PP instruction set 
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10.0 CYBER 170 STATE 

10.1.2 CURRENT CYBER 170 FEATURES NOT SUPPORTED 



10.1.2 CURRENT CYBER 170 FEATURES NOT SUPPORTED 

a) CPU * 
-Hardware error exit within CYBER 170 state 

- Hardware CMU instructions C Interoret i *e software) 

- CPU halt on error exit with Monitor Flag set 

- Dual processor configurations 

- Hardware initialization of CYBER 170 state 

- 017, 660 and 670 PASS Instructions are used for A170 
features (10.4.2) " 

b) 32K, 49K, 65K,' 98K, 196K Central Memory 
cl Extended Memory 

- OOP model OC 135 • 

- Extended, semiconductor memory in E?H mode 
d) Peripheral Processors 

- Status Control Register 

- Addressing 262K mamory via the A register 

- RPN instruction 

- Multiple PP speeds 

- 14 and 17 PP configurations land 20 PP configuration for 
SI). 

- 24XX, 25XX, 27XX, 641CH, 651CH, 661CH and 671CH PP 
Instructions are used for A170 features (10o4o2)« 

10.1.3 EXTENSIONS TO CURRENT CYBER 170 (A170I 

a) Required 

- Up to two million words of executable memory (Jobs 
restricted to 131K Ft) 
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10,0 CYBER 170 STATE 

10. 1.3 EXTENSIONS TO CURRENT CYBER 170 IA170I 
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10,0 CYBER 17(1 STATE 

10. S CYBER 170 STATE SOFTWARE 



- A single Job may address data arrays of greater than 
131K tsoft ECS> 

- Extended PP access to central memory 

- Very limited use of extended PP instruction set 116 bit 
instructions! 

- Support of C180 maintenance channel 
b) Not Supported 

- Single Job - s code area greater than 131K 

- Code and. data sharing 

- Security enhancements 

- Virtual memory . 

10.2 ££fiI£H£E&LS^U£EQ&I£a 

Refer to Appendix C for a list of peripheral equipment 
supported in CYBER 170 state. 

10.3 JE£S_CJaU£LES 

- Optional and supports ECS and ESM f In ECS mode only 

- Manufacturing cost objective is $10K/10th unit Uncludlng 

cabinet and cablel 

• NTBF Inherent objective Is 15,000 hours 

- Must be able to sustain a block transfer rate of one word 
every 100 ns 



10. *i mEPwLLft-SIAIEJSQEIHABE 



NOS/170 and NOS/BE operating system and product set software 
Hill Initially be modified to run on C180 hardware in C170 state 
with the then current 170 capabilities. A subsequent release of 
NOS/170 (and N0S/8EI will be enhanced to support Advanced CYBER 
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170 features. 

C170 SCOPE 2.0 software will not be supported on C180 
systems. 



10.*. 1 SOFTWARE MODIFICATIONS 



NOS and NOS/BE modification will be limited to those changes 
necessary to support the hardware differences listed in 
paragraphs 10.1.1 and 10.1.2. The modifications will be 
generally limited to the deadstart process* maintenance software, 
and PP routines which depend on timing characteristics* RPN or 
the Status Control Register. Exceptions may be granted by CPO 
system design, with AOiC approval. where the software 
modifications are minor or limited to support of specific CYBER 
180 RAM features, peripherals or performance. 

A CYBER 180 state system monitor Is required to execute 
specific versions of NOS and "NOS/BE In CYBER 170 state. This 
system monitor will be distributed In binary form. Source 
language, tools, and modifications to support non-standard 
systems will require a QSS. This monitor will hot exceed 1Q2S 
words central memory resldant on a 262K configuration* 

The A170 software modifications must lnsuret 

a) Oeadstart 

• Initialization and deadstart procedures are externally 
compatible. 

- A C171-C175 system Is able to deadstart and run specific 
versions of NOS and NOS/BE from the same deadstart tape 
or disk as an A170 system. 

- Memory and system Integrity are maintained when 
performing system Ini t lal Izat lon/daadstart and deadstart 
dumping procedures to guarantee proper 
restart /recover ab 1 1 1 ty. 

* A single deadstart dump capability which detects machine 
dependent conditions and presents all appropriate 
information to the user In a consistent notation. 

bl CPU 

- A consistent method of voiding the C170 and A170 
Instruction stacks for al I O.S. and Product Set 
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10.0 CYBER 170 STATE 

10*«».l SOFTWARE MODIFICATIONS 



software* 
cl Software Interpretation of CMU Instructions 

- when executing the CBL benchmark f paragraph 10*61 • the 
total P2 time required to simulate CMU instructions must 
not exceed 19 times the CP time required to execute 
these same CHU instructions on the base CYBER 73 with 
cmu. 

- No ' increase in 170 state memory requirements for system 
resident or individual Jobs* beyond that taken by the 
CYBER 180 state system monitor* 

- CNU instruction interpretation must be Inttrruptab le 
when execution time exceeds 0«3ms IP2I* 

- CHU Instruction interpretation must cause no changes to 
users object Codet l.e*» no recompl lation is required* 

- CHU instruction Interpretation solution must be the same 
for both NOS and NOS/BE. 

- Resource accounting for CHU interpretation must be 
chargeable to the user* 

- The CHU Instruction interpretation solution must not 
inhibit compatibility between C170 and A170 system in a 
multi-mainframe environment* 

• System throughput performance objectives as defined in 
Section 10*6 shall be achieved. (Benchmarks which 
realize more than 15X CPU time improvement between a 
non-CMU and CHU CYBER 73 need not meet these throughput 
objectives*) ' 



10.** 2 SOFTWARE ENHANCEMENTS 



8) 



NOS/1T0 only will be enhanced to extend the maximum amount 
of central memory supported from 262K words to 2H words* 
Since Jobs remain restricted to 131K of executable CM. 
this Imolies more concurrent Jobs and open files* Some 
Job mixes may not realize significant performance 
improvement with the Increased central memory* Extensions 
to NOS to relieve Job/file limitations will be kept to a 
minimum and In reaction to specific marketing situations* 

b) NOS/I70 *nd NOS/BE will be enhanced to allow a single Jobs 
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10. CYBER 170 STATE 

10.4.2 SOFTWARE ENHANCEMENTS 



data area in extended central memory to be greater than 
131K words tsoft ECS). Total executable memory 3nd soft 
ECS areas together cannot exceed 2 million words. Wher a 
configuration consists of .both hard and soft ECS. only 
soft ECS will be available for user access* 



c) Extended PP access to central memory will be provided 
NOS to support greater than 262K of executable memory. 



In 



dl Use of C180 extended 16-bit PP Instructions is allowed in 
C17Q state only where no other mechanism Is available to 
support the modifications or enhancements listed above. 
Any use of these Instructions In C170 state requires 
approval by ADtC. 



el On-I ine remote 
interfaces. 



maintenance* via standard communications 
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10,0 CYBER 170 STATE 
10.5 CPU PERFORMANCE 



10.5 ££iLP£EF2£!!A!i££ 



Using the Kernels 110 FTN Kernels* S-Profile* Cqmoositel* 
execute at the ratios! 



f + ... — • *» 

FTN ICommerclal ICOST AOOITION PERCENTAGE! 

Ex ecu t Ion I Execution ♦— -..- — » — .«•-.«•+ 

Ratio I Ratio I Total (11 IFlxed (21 

I (**) I Incremental I Incremental 

+ — «. — --••--!. — — — f 




1.0 

1.1 

2.9 

8.0 

3%.0 



I 



..I 

I 
I 



1.0 (311 



0.9 

1.5 

<t.O 

10.0 



N/A 
10.0 
%.8 
5.0 
No 



I Objective 



f- 



. — «. •- — .. 



I N/A 

I 7.5 

I 2.% 

I 3.0 

INo obj ectlve 

I 



(1) Total Incremental = total tenth unit CPU cost to provide 
CYBER 170 state 

(2) Fixed Incremental » that portion of the Incremental cost 
not subject to future cost elimination 

(3) CYBER 73 base uses the CHU 

(M A170 ratios are for recompiled non-CNU code on A170 
versus CNU code base on CYBER 73 
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10.0 CYBER 170 STATE 






10.6 SYSTEM PERFORMANCE 






10.6 SYSTEM ,EESEflSH£Lti£E 




1 
2 


Running the SBL benchmark (sclentltlcl a 


r\d CBL benchmarks 


3 

U 


(commercial • t achieve system 


throughout (elapsed 


5 


tlmel at the fol lowing ratios (CYBER 73/CYBER 


180M 


6 
7 
8 
9 


1 1 Scientific 1 Commercial 


1 Configuration 1 


1 II (2M3) 


1 , (St 1 


10 
11 
12 


1 1 I Elaosed 1 I Elapsed 


1 Mem 1 No. of 1 


1 I 1 Time 1 I Time 


1 Size 1 Disks 1 


1J 

m 

15 


1 II 11 


1 1 1 


1 CYBER 73 1 1 1.0 1 1 1.0 


1 131KW 1 2 1 


16 


I (1) I 1 II 


I 1 1 


ir 


1 II II 


I 1 1 


18 


1 SI 1 1 1.0 1 1 1.0 


1. 2MB 1. 5 1 


1 " 

1 20 


t 1 11 1 


1 1 1 


1 S2 1 1 2.5 1 1 2.1 


1 2MB 1 7 1 


21 


1 II 11 


1 1 1 


22 


1 , S3 1 1 7.5.U) 1 1 6.0 (VI 


1 «»M3 1 . 12 1 


23 


III 1 1 

1 THETA 1 I 25.0 Ik) 1 1 9.1 Ik) 


1.1 1 


2V 


1 8MB I 18 I 


25 


1 II II 


1 1 1 


26 
27 
28 






(1) Base system Is 131K CYBER 73 with CMU 


running NOS .1.1 


29 


level t*30/<»28. 




30 
31 


(2) A170 ratios use a recompiled non-CMU b 


ase versus CMU base 


32 


for CY8ER 73. 




33 


(3) The THETA commercial objectives are soft and subject to 


35 


change based on cost- return evaluations. 


36 






37 


ik) Multiple copies of the benchmark are run to achieve these 


38 


ratios (9 for S3 and greater than 25 for TMETA1. 


39 


1 




•iQ 


(5) The complete configuration Is given In 


the Configuration 


ki 


Notebook. 




kZ 
S3 


10.7 tfAltfEBAHE-CtOSIS 
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S7 


Mainframe costs are based on assumptions gl 


ven In !!•!• 


M 
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10. CY6ER 170 STATE 
10.7 MAINFRAME COSTS 
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10.0 CYBER 170 STATE 

10.8*1 MEAN TINE 8ETHEEN STSTEM DOWN INTERRUPTIONS (KTBI OOHN) 



t 

ISystem 


1 Processor t 


Memory 


1 


PP 


1 


Channels 


1 


Mainframe Cost 


1 


1 SI Entry 


1 I 
t 1 1 


1MB 


1 


10 


1 
1 


12 




t 93,300 




IS1 Target 

1 

tS2 Entry 


1 1 1 


2MB 


1 
l 


10 


1 

1 


12 




$105,800 




1 1 1 


1MB 


I 


10 


12 




$208,000 




152 Target 
t 

153 Entry 


1 1 


2MB 


1 
• 


15 


1 
t 


18 




$23i,roo 




1 i 

1 ' i 


2MB 


I 


10 


1 


12 




$335,000 




IS3 Target 


t 1 


(•MB 


t 


20 


1 


ZU 




$376,000 




1 


1 I 




1 




1 










ITHETA 




















1 Entry 


1 1 




1 




1 










ITHETA 


1 i 


SMB 


I 


20 


1 


Zh 




$1,172,000 




1 Target 


1 




1 




I 










I 


.A -*•.«••••< 




-♦ * 








-»« 




-t 



Packaging - The Initial entry and target systems have 3 
separate cabinets ICPU f Memory, IOUI costing an estimated 
$60-75,000. It Is a CfiLflUlr.fi US fiD± for S2 and an ttblfiCLtlYJa for 
S3 that subsequent packaging redesign accommodate these 
configurations In a manner which saves $25,000. 



10.8 BAH 



No separate CYBER 170 software support of CYBER 180 RAH 

hardware features Is planned. This means that degrading either 

processors (by-pass cache, MAPI or memory will necessitate a 
deadstart recovery. 



10.8.1 MEAN TIME BETWEEN SYSTEM DOWN INTERRUPTIONS IMTBI O0WN1 



1 
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3 
H 
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I 

IMTBI Cdn) (hrs) 
I 



TARGET 



S 1 



S Y S T E H 



170 mode 



♦ ♦ ♦ 

• POINT IN TIHE 1 CPU 1 MEMORY 
1 11 


•#■<■ 


I/O 


-f ....... .*. 

IPERIPHS! 
1 1 


O/S 1 

1 


TOTAL 1 
H/H 1 


TOTAL 
SYS 


1 On Release 


2251 -INC- 
i 




-INC- 


1 30001 


1501 


2091 


87 


ISlx Months 

1 

118 Months 1 

1 


2851 -INC- 

1 
3721 -INC- 

1 




-INC- 


1 30001 


2501 


2601 
1 

3311 
1 
--♦- 


128 


-♦- 


rlNC- 


1 1 

1 30001 
1 1 


5001 

1 


199 



4 — • 

I 

IMTBKdn) thrs) 



TARGET 



S 2 



SYS T E M 



i70 mode 



1 
















IPOINT IN TIME 1 


CPU IH 


EMORY 1 


I/O IPERIPHSI 


0/3 1 


TOTAL 1 


TOTAL 


1 [ 


.' 


1 


1 


1 


I 


H/H 1 


SYS 


tOn Release 1 

1 

ISlx Months 1 


t|50l 
i 


7001 

1 

8861 

1 

1158! 

1 

-- ♦ - 


k75\ 
1 


30001 
1 


loot 


ie<tt 

1 


62 


5691 


6011 


30001 


2001 


2051 


101 


118 Months 

I 


7ttk\ 
1 


7861 


30001 

1 
♦ - 


<*00l 
1 


2621 
1 
._ --♦- 


158 



f--.~ — ... — «... 

I 

IMTBKdn) Chrs) 

I 



TARGET 



S 3 



SYSTEM 



170 mode 




(On Release 




2701 


<*60t 


7031 


30001 


751 


1311 


W8 


1 




1 


1 


1 


1 


1 


1 




ISlx Months 




3621 


63UI 


7861 


30001 


1501 


1681 


79 


1 




1 


1 


1 


1 


1 


1 




118 Months 




5151 


8901 


9071 


30001 


3001 


2221 


128 


1 


.-+.. 


1 
... — «... 


1 


1 


1 
— #..- 


1 
....... — 


1 
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10.0 CYBER 170 STATE 

10.8.1 MEAN TIME BETWEEN SYSTEM DOWN INTERRUPTIONS (KTBI OQWNI 
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10.0 CYBER 170 STATE 

10.8.2 t#I> MEAN TIME BETWEEN SYSTEM OEGRAOEO INTERRUPTIONS 



♦--- ... ... 

I 

IMTBI(dn) IhrsI 

1 

t i 



TARGET 



T H E T A 



SYSTEM 



170 mode 



IPOINT IN TIME ! 
1 1 


CPU 1 MEMORY t 
1 I 


I/O IPERIPHSt 
t t 


O/S 1 


TOTAL 1 
H/W 1 


TOTAL 
SYS 


tOn Release I 
1 1 


1051 

1 > 


2551 

1 

(»00! 


718 1 


30001 


501 

1 

751 


661 


28 


ISi x Honths 1 
1 t 


1MI 
1 

2001 
1 


1 
76V 1 

1 
8311 

1 


1 

30001 


1 

891 


%1 


118 Months 1 
I 1 


613! 
! 


1 

30001 
1 


1 
1001 

1 


1 

1221 

1 


55 



f . 4 — ....... . 4 

INC weans Included in the CPU. 
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10.8.2 (II) MEAN TIME BETWEEN SYSTEM OEGRAOEO INTERRUPTIONS 



+ ....... . 

I 

IHTBI(dg) (hrs) 

t 



TARGET 



S 1 



S Y S J E M 



170 mode 



+...... — .. 

tPOINT IN TIME 


1 


► -.+ . — ♦- 

CPU IMEMORY 1 


I/O 


IPERIPHSI 


O/S 


» 1 


— --- — ♦- 
TOTAL 1 


TOTAL 


1 


1 


1 1 




1 1 




1 


H/W 1 


SYS 


lOn Release 


1 


INFIN.I -INC- 1 


-INC- 


1 90001 




61 


76271 


6 


1 


1 


1 1 




1 1 




1 


1 




ISlx Months 


1 


INFIN.I -INC- 1 


-INC- 


1 90001 




101 


76271 


10 


1 


1 


1 1 




1 1 




1 


I 




118 Months 


1 
1 


INFIN.I -INC- 1 
1 1 


-INC- 


1 90001 
1 1 




211 
1 


76271 

1 


21 



4. — - — ... — 

I 

1MT8I(dg) (hrs) 



TARGET 



S 2 



SYS T E M 



170 mo do 



♦ -- -— — -- — — t- 
IPOINT IN TIME I 
I I 



-. 1.. ...... 4........ . f *..... — f. ..» — . 

CPU IMEMORY I I/O IPERIPHSI O/S I TOTAL 1 TOTAL 
I I I I I H/W I SYS 



lOn Release I INFIN.I INFIN.I INFIN.I 90001 k\ 

t 1 I 1 I I I 

ISlx Months 1 INFIN.I INFIN.I INFIN.I 90001 81 

! It I I I I 

118 Honths I INFIN.I INFIN.I INFIN.I 90001 171 

I I I I I I I 

+ -•-•» — ....|........f........f.......t ....*.-••-•.*.- 



90001 
I 

9QG0I 
I 

90001 
I 



n 

17 



I 

IMTBI(dg) (hrs) 

I 



TARGET 



S 3 



S Y STEM 



170 mode 



IPOINT IN TIME I 
I I 



CPU 



IHEMORY I 
I I 



I/O IPERIPHSI 
I I 



.... — *.......*....... 

O/S I TOTAL I TOTAL 
I H/W I SYS 



lOn Release 


1 


1 


1 


ISlx Months 


1 


1 


1 


118 Months 

1 

+..... — ..... 


1 
1 

— ♦ 



INFIN.I INFIN.I INFIN.I 90001 
I I I I 

INFIN.I INFIN.I INFIN.I 90001 

I I I I 

INFIN.I INFIN.I INFIN.I 90001 
1111 
-f §.. *-. *. 



31 


90001 


1 


1 


61 


90001 


1 


1 


131 


90001 


1 


1 



3 
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10,0 CYBER 170 STATE 

10.8.2 If I> HEAN TINE BETWEEN SYSTEM OEGRAOEO INTERRUPTIONS 




t 

tMTBIfdg) 

1 


(hrs) 


TARGET THETA SYSTEM 170 mode 


IPOINT IN 

1 


TIME 1 
1 

■--- — f- 


CPU IMEMORY 1 I/O IPERIPHS! O/S 1 TOTAL 1 TOTAL 
f 1 t 1 1 H/H 1 SYS 

f + — . — — 4. . — + — i 1 — f - — 



lOn Release I INFIN.t INFIN. I INFIN.I 90001 21 90001 

f I I I I t I I 

ISlx Months I INFIN.t INFIN.I INFIN.I 90001 31 90001 

I II I I I II 

116 Months I INFIN.I INFIN.I INFIN.I 90001 <it 90001 

I I II I 1 II 



INC <i«ans included in the CPU. 

INFIN. means no redundancyt So any failure causes 
interruption. 



system 
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10.0 CYBER 170 STATE 

10.8.3 MEAN LOST TIME OUE TO SYSTEM DOWN 'INTERRUPTIONS IMLT OOWN1 

10.8.3 MEAN LOST TIME OUE TO SYSTEM DOWN INTERRUPTIONS IMLT OCHNI 

The Mean Lost Time Is defined in units of minutes per 

failure* Objectives for ■ Sl-THETA t systems are shonn in the 
fol lotting tables. 



IMLTCdn) fminst 
I 



TARGET 



S 1 



SYS T E M 



170 mode 



IPOINT IN TIME 

1 


-f- 


CPU IMEMORY 1 
1 1 


I/O 


.* ....... *- 

IPERIPHSI 
1 t 


O/S 1 

1 


TOTAL 1 
H/W 1 


TOTAL 
SYS 


lOn Release 




1501 
I 

1501 
1 

1501 


-INC- 1 


-INC- 


1 1801 
1 | 


361 

1 
361 


1521 
I 

1531 
1 


8*4 


ISlx Months 

1 

118 Months 

1 




-INC- 1 


-INC- 


1 1801 


93 




-INC- 1 


-INC- 


1 1801 
1 1 


361 
1 


1531 

1 


107 



I 

IHLTCdnl (mlnsl 



T A R.G E T 



S 2 



SYSTEM 



170 mode 



4..-..-... ...... 

IPOINT IN TIME 
1 


»♦- 


CPU IMEMORY 1 
I 1 


I/O IPERIPHSI 
1 I 


— - — -♦- 
O/S 1 

1 


•♦- 

TOTAL 1 
H/H 1 


TOTAL 
SYS 


lOn Release 

1 

ISlx Months 




1501 

1 

150J 


1201 

1 

1201 


1501 

1 

150 1 


1801 

1 

1801 


2<#l 

1 

2m 


1<»5« 

1 

i<«5! 


70 
8«» 


1 

118 Months 

1 




1 

1501 

1 


1 

111! 

1 


1 
1501 

1 


1 
1801 

1 


i 

2M 


1 

1 
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10.0 C,Y0ER 170 STATE 

10.6.3 MEAN LOST TIME QUE TO SYSTEM DOWN INTERRUPTIONS CMLT OOWNI 
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10.0 CYBER 170 STATE 

10.8.«i MEAN LOST TIME OUE TO SYSTEM OEGRAOEO INTERRUPTIONSIMLT OGI 



+—.. -• 

I 

l-MLTfdnl twins) 

I 



TARGET 



S 3 



SYS T E M 



170 mode 



f. 

IPOINT IN TIME 
1 


•I— 


CPU t MEMORY 1 
1 t 


I/O IPERIPHSI 
1 1 


O/S 1 

1 


— •• — ♦- 

TOTAL 1 

H/H 1 


TOTAL 
SYS 


lOrv Release 

1 

ISlx Months 




1501 
1 

150! 
1 

1501 
1 


1201 
1 

1201 
1 

1111 
1 


1501 

1501 
i 


1801 

1 

1801 
1 


181 

1 

181 
i 


1 

lt»t>f 

• 


63 
17 


118 

t 


Months 




1351 
1 


1801 


15! 
1 


139! 
1 


87 



IMLTCdn) (wins! 

t 



TARGET THETA 



SYSTEM 



170 mode 



♦ — m f 

IPOINT IN TIME 1 
1 ( 


CPU IMEMORY ! 
1 I 


••• — -♦ — • — ♦- 
I/O IPERIPHSI 
1 ! 


O/S ! 

! 


.— — — ♦• 

TOTAL 1 

H/H 1 


TOTAL 
SYS 


!On Release I 


210! 


150! 

i 
150! 

! 

150! 

1 


135! 

! 
1351 

1 
1261 

! 


1801 


121 


1871 
1 

1871 
1 

18d! 
* ! 


87 


ISlx Months 1 
1 t 
118 Months ! 
1 1 


2101 

2101 

! 


180! 

1801 

1 


i 
12! 

! 
12! 


92 

90 



INC means Included ln the CPU. 
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10. 8. * MEAN LOST TIME OUE TO SYSTEM OEGRAOEO INTERRUPTIONSIMLT OGI 



♦----_ 

I 

IMLTfdg) (fitns) 

I 



TARGET 



S 1 



SYSTEM 



170 mode 



♦.- — +- 

IPOINT IN TIME 1 


CPU 


,-f . f. — 

1 MEMORY 1 I/O 


.1- f.- 

IPERIPHSI 


♦- 

O/S ! 


♦« 

TOTAL 1 


TOTAL 


1 1 




1 » 


I 1* 


1 


H/W 1 


sirs 


ICn Release 1 




01 -INC- I -INC- 


1 1051 
1 1 

1 1051 


101 


891 


10 


ISlx Months 1 
! 1 
116 Months 1 
I 1 




0! -INC- 1 -INC- 

1 I 
0! -INC- 1 -INC- 

I 1 


101 


691 


10 




1 1051 
1 1 


lot 

I 


89! 

1 


10 



I 

IMLTtdgJ (mlnsl 
I 



TARGET 



S 2 



SYS TEH 



170 mode 



IPOINT IN TIME 1 


CPU 


•-♦ — - — --♦- 

IMEMORY 1 
I 1 


I/O 


IPERIPHSI 
I 1 


O/S 


--♦- 

1 
1 


-- — --*- 

TOTAL 1 
H/H 1 


TOTAL 
SYS 


!On Release I 
1 1 

ISlx Months 1 
1 1 
118 Months I 
1 1 




or ot 
i i 

0! 01 
! 1 

01 01 
1 I 




01 

1 

01 

1 

01 

1 


1051 
1 

1051 
I 

1051 
1 




61 

I 

61 

1 
6! 

1 


•. 1051 

I 

1051 

1 

. 1051 
1 


6 
6 
6 



TARGET 



IHLT(dg) (mins) 

I 



S 3 



SYSTEM 



170 mode 



IPOINT IN TIME 
I 



CPU IMEMORY I I/O IPERIPHSI O/S 
I I I I 



I TOTAL I TOTAL 
I H/W 1 SYS 



+ -.--•-. «--.--.f---.---t--.----f---.---f f •!■ •♦ ._-_ 



IOn Release 

I 

ISlx Months 

I 

118 Months 

I 



01 


01 


01 


1051 


m 


1051 


1 


1 


1 


1 


i 


1 


01 


01 


01 


1051 


<♦! 


1051 


1 


1 


1 


1 


1 


1 


01 

I 


01 

1 

— -~+ — 


0! 

1 


1051 

1 


i 
--•-♦ — 


1051 
1 
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10.0 CYBER 170 STATE 

10.8.% MEAN LOST TIME OUE TO SYSTEM DEGRAOED INTERRUPTIONS CMLT DG) 
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10. CYDER 170 STATE 
10. 8. 7 NET AVAILABILITY 



IMLTtdg* (ainsl 

I 



TARGET 



T H E T A 



SYSTEM 



170 mode 



IPOINT IN TIME 1 


CPU 


t MEMORY 1 


I/O 


— f— — -— -1— 
IPERIPHSI 


o/s 


— 4. 

1 


TOTAL 1 


TOTAL 


I 1 




t 


1 




1 


1 




1 


H/H 1 


SYS 


lOn Release 




01 


Of 




01 


1051 




21 


1051 


2 


1 




1 


1 




1 


1 




1 


J 




ISlx Months 

1 1 


• 


01 
1 


01 

1 




01. 

1 


1051 
1 




2) 
I 


1051 
1 


2 


118 Months 




01 


0! 




01 


1051 




21 


1051 


2 


r 




1 


1 

— *- 




t 


1 




1 


1 





INC means Included In the CPU. 

Zero MLT occurs when all failures era Interrupts* l.e«* no degraded 
failures. 



10.8.5 OATA ERRORS 



a) Recoverable Oata Errors 
To be furnished 

bl Unrecoverable Oata Error* 
To be furnished 

c) Undetected Oata Errors 
To be furnished 



10.8.6 USER AVAILABILITY 



To be furnished 



10.8.7 NET AVAILABILITY 



The objectives lncludi! 

- the time taken for an engineer to get to the site to repair the 
failure. 

- the time taken to effect the repair IMTTRI. 



1 

2 

3 

h 

5 

6 

7 

8 

9 

10 

11 

12 

13 

iU 

15 

lis 

17 

18 
19 
20 
21 
22 
23 
ZH 
• . 25 
26 
27 
28 
29 
30 
31 
32 
33 
3<t 
35 
36 
37 
36 
39 
V0 

<i2 

*»3 

k5 
d6 
V7 
%6 
<i9 
50 



the time taken to restore the system to Its original state and 
re-run time necessitated by the failure. Weighted rerun times 
are used In the calculations* based on the falling equipment 
type. 



time taken on preventive maintenance* assuming this is 
by a single engineer.- 



conducted 



1 
2 

5 

6 

7 

6 

9 
10 
11 
12 
13 
1H 
15 
16 
17 
18 
19 
20 
21 
22 
.23 

25 
26 
27 
?3 
29 
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31 
32 
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36 
37 
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39 
««0 
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UZ 
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U6 

Ufi ' 
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10.0 CYBER 170 STATE 
10. 3. 7 NET AVAILABILITY 

The objectives exclude! 
.- time to make changes to the hardware (FCQ*sK 

- time to maKe changes to the software (PSR*st* 

f « . ..-.———. — -.»...•* 

I t 

I SYSTEM AVAILABILITY OBJECTIVES - CYBER 170 I 

• " -I ' . 

4. . _ f_. *•__.. f „„ -* — -♦ 

1 I I I . I I 

ITIME PERIOD I SI I S2 I S3 I THETA I 
I I I I I I 

f. . 4. >_. «_4 • — — . -f------ -4. 

11111! 
10n Release t 98.11 I 97.50 f 97*09 I 93.76 I 
I 1.1 I I I 

16 Honths I 90.51 I 96.06 I 97.66 I 95.12 I 

1 lit I I 

118 Months I 98.83 I 98. M I 96.16 I 96.18 I 

1 II 1 i t 



10.8.8 MAINTENANCE SOFTWARE 



All Maintenance software objectives In this document are the same 
as CYBER 180 objectives unless specifically stated for dYBER 170 
state. 
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11.0 COMPONENT CHARACTERISTICS 



5 
6 
7 
8 
9 
10 
It 
12 
13 
1<i 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2<# 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3V 
35 
36 
ST 
36 
39 
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*1 
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%8 
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11.0 CUIl£ilN£HIj:dfl£^I£SISIICS 



11. 1 CJMlfmENT CQSLJiaaE£mES 



- Processor and memory costs are for the 10th unit. 

- The manufacturing learning curve Is assumed to.be 90X exclusive 
of cost Inflation. 

- The ireuory and processor costs are quoted for the year In which 
the 10th unit would be. sold according to the forecasts in 
Appendix E. 

- System Test and Checkout ISTCOI costs are included on a 
component basis. All system tests beyond STCO are cost of sales 
incurred by Systems Olvlslon and not Included in manufacturing 
standard cost. 

- Cost inflation rate for mainframe components is assumed to 
continue at rate'of most recent five years. 



11*1.1 CPU-S 



Target 

MFG Cost 



P2 (no optlonsl 



72*000 
(«,500 



Options al 16K byte cache 
iperf ormance! 
b) Performance Monitoring 2*000 
Facility 

PS (no options) 18«i»000 

d> 16K byte cache 8*000 

tperf ormance) 
e) Performance Monitoring 2*000 
Facility 

. THETA CPU (Including Performance 550*000 
Monitoring Facility! 



I 
2 
3 
i» 

5 

6 

r 

6 
9 
10 
11 
12 
13 
1<* 
15 
16 
17 
18 
19 
20 
21 
22 
23 
ZU 
2* 
26 
27 
28 
29 
30 
31 
32 
33 
ZH 
35 
36 
37 
38 
39 
«.0 
«.l 
«»2 

<»<• 
*5 
«.& 
i»7 

hn 

*9 

50 
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11.0 COMPONENT CHARACTERISTICS 
11.1.2 Si 
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11.0 COMPONENT 
11.1.3 MEMORY 



CHARACTERISTICS 



ll.l.Z SI 



Basic SI Includes! 



Target 
MFG Cost 

75,800 



1 PI 

1 Ml with 1M byte 

I SI IOU cluster with! 

-5 PR's 

-8 CYDER 170 I/O Channels 

-iraintenance channel connections to PI I HI 

-2 port MUX (for console) 



SI Mainframe add-ons 

1M byte Central Memory 
Increment* applies up to 
a total of <iM bytes 

5 PP increment 

applies uo to a total of 

10 PP*s 

2 Channel increment 

aoolies up to a total size 
of 12 channels 



11.1.3 MEMORY 



ttAJUaC^jt^iiK-XJtlifl 



H2- 


1 


(HB) 


M2- 


2 


(MB) 


N2- 


* 


tH0» 


H2- 


•6 


1MB) 


M2- 


8 


(MB) 


M2- 


12 


' (MB) 


M2- 


16 


> (MB) 


H3- 


•2 


1MB) 


M3- 


•<» 


(MB) 


M3- 


-6 


(MB) 



7*500 



3*500 



1*508 



Target 
MFG Cost 



72*000 
78*000 
89*000 
10<»*000 
115*000 
l<tl*000 
166*000 

85*000 

98,000 

115*000 



1 

z 

3 

h 
5 
6 

r 

8 
9 
10 
11 
12 
13 
1% 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Z*» 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3* 
35 
36 
37 
38 
39 
40 

*i 

*2 
S3 

UH 
HS 
<t6 
hT 
%8 
%9 
50 



H3-8 < 
M3-12 
M3-16 


(MB) 

(MB) 
(M8) 


lJJi 


mm 


:xjL.Ii-£K-JItila 


k MB 
8 HB 
12 MB 
16 MB 





125,000 
155,000 
180.000 



330*000 

530,000 

860*000 

1,050,000 



1 

2 
3 
% 

5 
6 

r 

8 
9 
10 
It 
12 
IS 
ik 
15 
16 
17 
1A 
19 
20 

22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3«t 
3* 
36 
37 
38 
39 
CO 
M 
S?. 
M 
*V 
•.5 
V6 
\T 
H6 
VJ 
50 
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11.0 COMPONENT CHARACTERISTICS 
11.1. % STANO-ALONE I/O UNIT (IOU2I 



.1.1. «• STANO-ALONE I/O UNIT (IOU2) 



Oaslc I/O Unit Includes 

- 5 PP's X « Channels 

- 2 Port MUX 

- 2 maintenance channel 
connections 

Additional 5-PP Increments 
fuo to a maximum of 20 PP*sl 

Additional 2-Channel increments 
(up to a maximum of 2% Channelsl 

Ootloral maintenance channel pair 
connections (up to a maximum 
of 6 connections! 



Target 

HFG Cost 

<i7,000 



3*000 



1,500 



TOO 



11.1.5 OTHER 



Motor Generator Set 



♦ -- — ♦- 

1 1 


-.---< 


t ••.•—•.•.-. 


.♦-_-.-- 


1 




IKVA 1 Frequency! 


Rlde-ThrufQuietl 


zedt 


Target 


1 1 


iHz) 1 


(Secsl 




ICost ($> 


I I 








1 




112.51 


50 


0.075 


1 fes 


1 


9750 


112.51 


60 I 


0.075 


1 Yes 


1 


7<«00 


t 1 








1 




125.01 


50 


1 0.5 


t No 


1 


9000 


125.01 


60 • 1 


0.5 


1 No 


1 


9000 


125.01 


50 1 


2.5 


t Yes 


t 


13000 


125.01 
1 t 

IU0.0I 


60 1 


2.5 


1 Yes 


I 
I 

1 


13000 


50 1 


2,5 


t No 


13000 


mo. oi 


60 


1 2.5 


1 No 


1 


13000 


t i 








1 




150. 01 


50 


1 2.5 


1 No 


1 


22000* 


180.01 
1 I 
♦ -♦- 


60 


1 2.5 


1 No 


1 

1 


22000* 



1 
z 

3 

<• 
5 
6 

7 
8 
9 
10 
11 
12 
13 
1* 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zk 
25 
26 
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39 

to 

%l 
kZ 
*3 

*♦<• 

%6 
•♦7 
«t8 
%9 
50 



11.0 COMPONENT CHARACTERISTICS 
11.1.5 OTHER 



* Approximate figures. 



Power Control Panel 

SI 

S2-THETA*w/0ewpoint Sensing 

Optional 

Environment Monitor 

Console (752) 

High-performance Console 

High-performance Console 
Controller 

S2 and above 
SI 

Power Control Panel 
Including Oewpolnt Sensing 



Target 
MFG Cost 



2,000 
2 f 700 



5,000 
1,000 
7,700 



800 
500 

2,700 



11.2 £fltt£flB£H1[ HAIUI£HAJiCJLJ:ftaL-aa>i^Il^S 



The monthly maintenance cost for CYBER 180 mainframe components 
Incurred by the supporting field service organization must not exceed 
the following levels (expressed as a percentage of manufacturing 
cost!! 



1 Mainframe 
1 Component 


Life Cycle 
Average Monthly 
Maintenance Cost 


Second Year 

Monthly Maintenance 

Cost Objective 


1 si 


0.67X 


<5 t l0> 




0.85JC 


i7S0> 


1 P2 


0.6U 


CM3D> 




0.76* 


■CSM5> 


1 H2 


0.<»2X 


*3b0> 




0.52X 


CMb2> 


1 P3/H3 


0.51X 


U5M0> 




0.6«U 


W70} 


1 THETA 


1 0.ti<«X 


{MttO> 




0.5«iX 


{5fiD0> 
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! * 

« 9 
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12 
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!<• 
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16 
17 
18 
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2? 
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3t 
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*J 

*S 
Hb 
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%9 
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11.0 COMPONENT CHARACTERISTICS 
Hl™!?rr™!?LI!f INTENANCE C0ST OBJECTIVES 

\ I0U i °'* 5 * <3fl > t o.siz {qa > I I i 

""" * * ♦ s 

Thes* costs are defined to include both the direct cost r>f 5 

« s n r &V?;: rr n nt T 8 h nd H th i 9 i 8M A cation ° f -/*'- 1^^^^ i 

as oescri&ed in a-3.2.i* The dollar figures are giveni for information-., t 
configuration?* fi ^^s for the IOU represent a 10PP, IS channel | I 
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If 
18 
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21 
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23 
?4 
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26 

zr 

28 

29 
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39 
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43 

<♦<♦ 
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11.0 COMPONENT CHARACTERISTICS 

11*3 COMPONENT RELIABILITY OBJECTIVES 



11.3 MttfMEJfclLfiELlAfllUlJLflBilECLlStES 



+••_•«._. — f f . f ^ . „ •— -«. 

I IFuncfl lEIemntl I MTTR tmlnsl t 

ICOMPONENT UnherM llnherent I I 

I I MTBF I NfBF I * I 

f f f 1 « «. «. «. 

1 I (Hours)! (Hours) IReleasel 6Hthsll8 Hthsl36 Mthsl 
♦ — • + f f ,. f * f .« f 

I ! ! ! I III 

IS1 Mainframe, 1MB t 1600 I 1300 1 60 1 60 I 45 t 30 I 

I I I I I J 1 I 

IP2 Processor 1 2250 I 1800 I 60 I 60 I 45 1 30 I 

I It 1 I t CI 

IP3 Processor I 2570 I 1800 1 60 I 60 I 45 % 30 I 

t II I I I I I 

ITHETA Processor I 760 I 700 I 120 I 120 I 90 I 60 I 

I I I I I I I I 

♦ f f • — «... f ,. #..—._-.«. 

I I I I t I I I 

IM2-1 Hewory I 2800 I 1400 I 30 I 30 I 20 I 15 I 

IM2-2 Mercery I 2300 I 900 I . 30 I 30 I 20 I 15 I 

IM2-4 Memory f 1700 I 600 I 30 I 30 I 20 I 15 I 

IH2-6 Hemory I 1350 I 500 I 30 I 30 I 20 I 15 t 

1M2-8 Memory I 1100 I 403 I 30 I 30 I . 20 I . 15 I 

IM2-12 Memory. I 800 I 335 I 30 I 30 I 20 I 15 I 

IH2-16 Memory I 700 I 270 t 30 I 33 I 20 I 15 I 

I II I I I I I 

IH3-2 Meircry I 2300 I 900 I 30 I 30 I 20 I 15 I 

IH3-4 Hemory I 1700 I 600 I 30 I 30 I 20 I 15 I 

IH3-6 Memory I 1350 I 500 I 30 I 30 I 20 I 15 I 

IH3^8 Memory I 1100 I **00 I 30 I 30 I 20 I 15 I 

IM3-12 Memory I 800 I 335 I 30 I 30 I 20 I 15 I 

IM3-16 Memory I 700 I 270 I 30 I . 33 I 20 I 15 I 

I II I I I I I 

ITHETA-4 Memory I 1350 I 500 I 30 I 30 I 20 I 15 I 

ITHETA-8 Memory I 1100 I V00 I 30 I 30 I 20 I 15 I 

ITHETA-12 Memory I 600 I .335 I 30 I 30 I 20 I 15 I 

ITHETA-16 Memory I 700 I 270 I 30 I 30 I 20 I 15 I 

f-.- „-. — ♦-- .-* — •♦ -♦— ♦ — - — • -♦•—.— -f 

I I I I I I I I 
II/O Unit I (See I (See I 60 I 60 I 45 I 30 I 
I I BelowM Below! I I I I I 
t I I I I I I I 
f -.--- — — .-..„_... * + ...... »• ...♦.-- * — ----- f — — .«-f 

(System Power I 145000 I 120 I 120 I 120 I 120 I 
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11.0 COMPONENT CHARACTERISTICS 

11,3 COMPONENT RELIABILITY OBJECTIVES 
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11«0 COMPONENT CHARACTERISTICS 

11. k COMPONENT CONFIGURATION OBJECTIVES 



The functional and elemental Inherent MTBF objectives for the 
stand-alone IOU are Identical for each configuration. Representative 
IOU configurations are shown belowl 



f ———-——•« 

I CHANNELS 

PPU«S*~ * * 4- •— 

I I I I I 

I 8 I 12 I 16 I 20 I 2% 
I.I I I ' I 

II I I I 

5 I 2900 I 2800 I 2600 I 2500 I 2300 
I I I II 

— f- • •+•• *■-- — -.+----^ -+-.-.- 

I 1 I II 

10 I N/A I 2500 I 2300 I 2200 I 2100 
I II I I 

„#. * + f f 

I II I I 

15 I N/A I N/A I 2000 I 1900 I 1800 
I I I I I 

I I II I 

20 I N/A I N/A I N/A I 1700 I 1600 
I I I I I 

.4. *,. --4... ....!■. __..__* 



The functional and elemental Inherent MTBF for the Configuration 
and Environment Monitor ICEM1 Mill exceed 15000 hours. 
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29 
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tt.k COMPON ENT C ONFIGURATION OBJECTIVES 



ll.U.l CENTRAL MEMORY SIZES 



The major requirements for central memory sizes of two megabyte and 
below for the Ml f M2 and M3 are to provide 3dJltiona! models In CYBER 
170 state. The memory sizes identified are the Increments to be 
offered from a marketing standDolnt. This doas not mean that costs 
must be directly relatable to memory sizes. 



afiOicaJLiiaa&rj£_£iZ-ft 



1 


MB 


2 


MB 


3 


MB 


U 


MB 


5 


MB 


6 


HB 


7 


MB 


8 


MB 


10 


MB 


12 


MB 


Id 


MB 


16 


HB 


20 


MB 


ZS 


MB 


28 


MB 



32 MB 



x 

X 

X 
X 
X 
X 
X 
X 



uz 

X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 



113 

X 
X 
X 
X 



IHEIA 



1 
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3 

«» 

5 
6 
7 

ft 

9 
10 
11 
12 
13 
XU 
15 
16 
If 
in 

20 
21 
22 
23 
2<* 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3H 
55 

jr, 

3' 

34 

39 

*»0 . 

«.i 

s> 
s\ 

su 
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Sf 
V* 
«i9 
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11. COMPONENT CHARACTERISTICS 

li.4.2 CENTRAL MEMORY OEGRAOE CAPABILITY 
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12.0 APPENOICES 



11.«».2 CENTRAL MEMORY OEGRAOE CAPABILITY 



Central memory degradation Is required primarily In CYBER 1J0 state 
operations- A physical switch In Ml» M2» H3 or THETA reduces memory 
caoaclty by an Increment that varies depending on the falling 
addressees)? but In no case to a degraded sice less than the minimum 
shown below (except THETA <iH8 memory Is not degradablel* 

Initial HfiDlcalJlamftC3i-Sifcft ttJLaliayffl Pgqradad,^lza 



2-3 MB 

<»-r M8 

8-12 MB 
l«i MB 
16-2V MB 
26 HB 
32 HB. 



1 MB 

2 MB 
k MB 
6 MB 
8 MB 

12 MB 

16 MB 



11.5 CjftUEJjJJAR.UXit 



The calendar Ufa ior all CYBER 180 mainframe component* Is not 
less than ten years* 



11.6 EBOmJUEUiAmEMm&JLfctll 



The ruifber of hours or preventive maintenance per 1000 scheduled 
operating hours shall not exceed the numbers quoted below. This 
Includes •'hands-on" PH as well as PM performance from a remot# 
location^ but excludes PM normally performed by an operator* 



Mainframe 

Comoonent 

SI 

PZ 

M2 
P3/M3 
THETA 
IOU 



Hours PM per 
1000 Hours Operated 

1.5 

1.5 

1.5 

3.0 

8.0 

1.5 



1 
2 
3 
k 

5 

6 

7 

' 8 

9 

10 

11 

12 

13 

1* 

15 

16 

118 
19 
20 
21 
22 
23 

-?* 
25 

26 
27 
28 
29 
30 
31 
32 
33 
3% 
35 
36 
3f 
38 
39 
*Q 
<il 
hi 
*3 
hk 
<*5 
«♦& 
H7 
<f8 
<i9 
50 
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12o 1 l£l_AEEEtitllX A - PatBLfl£tt£tUL-CLQSX 



The following cost forecast appeared In the CYBER 180 Program 
Plan» Rev. Et dated 0<»^15/r8. Check the Program Plan. Apoendlx 
Ct for the most current cost forecast* 



totk r tii-inj|"y ir 



FUMING tYPC ,R*t> and PCS, 



tin costs 



REPORT BATES M/15/78 















YCi» 


- * - 


' 










PRODUCT 


PRIOR YR« 


1178 


1171-^ 


1180 


1^81 


l'i = 2 


Hfo* 


1'JSM 


1185 


l c »cb 


rir.i P E 


t:t«l 


RtP 


























Hirdwar* 


13883 


13573 


IM531 


12137 


11110 


7207 


1.878 


31b0 


221b 


2W32 


T2S3 


1bS36 


Softvart 


3512 


3b75 


tl83 


1381 


1057S 


8238 


7813 


7b5l 


7500 


7530 


13303 


85188 


Publication* 


an 


MSO 


86(i 


1M82 


1513 


17ib 


178M 


13bb 


1?50 


lib? 


3810 


1S803 


NPP 


l^b 


b20 


u,s 


7S0 


880 


ISO 


1020 


1050 


1050 


1050 


33S0 


12M81 


Subtotal 


11220 


16318 


22273 


237S0 


2M238 


18111 


17575 


13227 


1201b 


12131 


2Ub3 


210010 


StSl 


























Hardware 


SO 


73 


127 


1313 


2800 


3818 


MOOT 


3111 


28M1 


2b31 


b23b 


?80bS 


Software 











SI 


105 


1S8B 


18 lb 


1771 


1855 


11M8 


15C33 


271MM 


Publications 








22 


2><0 


378 


283 


28b 


MSb 


525 


MSI 


12H 


3131 


Subtotal 


SO 


73 


mi 


lb8«4 


3283 


571.1 


bill 


b23M 


5221 


5030 


25527 


511««Q 


TOTAL 


ii270 


18Sb7 


22M22 


2SW3M 


27521 


53880 


dJbSb 


llsbl 


17325 


171b1 


S^S«iO 


JbllSO 



3 

<♦ 
5 
6 

r 

8 

9 
10 
11 
12 
13 
IV 
15 
16 

ir 

18 

19 

2D 

21 

22 

23 

2U , 

2? 

2-3 

IT 

21 

29 

3U 

31 

3<: 

3$ 
3<« 

33 
3b 
3T 
3* 
3 3 
«i0 
M 
«♦? 

uu 
k* 

M, 
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12.0 APPENOICES 
12.2 APPENDIX 8 



CY9ER 180 SYSTEM DESIGN OBJECTIVES 



12.2 A£££tJQiJL.a.^JIia£R-Hm-SIStEH_DES IGN 03 JECT IVES 

The Si, S2, S3 and THETA Systems will conform to the 
objectives stated in the main body of this Architectural 
Objectives/Requirements document. This appendix describes the 
unique characteristics of the Sl f $2, S3 and THETA Systems as 
they fall within the range of the CYBER 180 product line. 

For CYBER 180* this document takes the place of the various 
System Design Objectives <D0t documents usually written for a new 
product line. Information normally found in a System 00 but not 
included in the body of the Architectural Objectives/Requirements 
is contained in this appendix. 
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3 

k 

5 

6 

7 

8 

9 

10 

11 

12 

13 

Id 

15 

16 

If 

16 

19 

20 

21 

22 

23 

ZH 
25 
26 
2F 
28 
29 
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33 
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12.0 APPENDICES 

12.2 APPENDIX - CYBER 180 



SYSTEM OESIGN OBJECTIVES 



OBJECTIVE 



SI 



Sche du I e/H 1 1 est one I APP.F 

I 
Target Lease Rangeltl<t-35K 

I 
System IAPP.0 

Configurations I 

I 
Number of CPU's 11-2 

I 
Memory I 

-Size UHB-8MB 

-Number of Memory 13 

Ports I 

-Memory InterleaveI<t-8 
-Reconfigure/ llnterleave/ 
Haroware Inon-lnterl. 
-Reconfigure/ IPage Size 
Software II512B-65K3) 

I 
I/O I 

-Concurrent I/O 118 contr. 
-I/O Bandwidth 112 MB/s 
-Maximum Periph- 12 MB/s 
er8l Rate I 

I 
System Per formance ISec. 7 

I 
System Rel iabi I i ty ISec.8 

I 
System ISec.8 

Availability I 

I 
Manufacturing CostlAPP.D 

I 
System HaintenancelSec.8 
Cost I 

t 
FCO Rate ISec. 8 

I 
PSR Rate ISec. 8 



MB - Megabyte 

TBF * To Be Furnished 







. 


1 


1 


1 


1 


2 


1 S2 


1 S3 


1 THETA 


3 

«♦ 

5 


1 


1 


1 


IAPP.F 


•IAPP.F 


IAPP.F 


6 


1 


1 


1 


7 


IS30-65K 


U50-120K 


IT9F 


8 


1 


1 


1 


9 


IAPP.0 


IAPP.0 


IAPP.D 


10 


1 
1 


1 
1 


1 
1 


11 
12 


11-2 

I 
1 


11-2 
I 

1 


11-2 
1 

1 


13 
1*« 
15 


I1MB-16MB 


l2iB-32MB 


l«*HB-16MB 


16 


1% 

I 


15 
1 


15 
1 


17 
18 


IW-8 


18-16 


116-32 


19 


1 Inter 1 eave/l Interleave 


/ 1 Inter 1 eive/ 


20 


Inon-interl 


• Inin-lnterl 


• Inon-lnt er I • 


21 


IPsge Size 


IP*ge Size 


IPage Size 


22 


1 (512B-65KB) 1 (5128-65KBI 1 (512B-65K3) 


23 


1 


1 


1 


2<» 


1 


1 


1 


25 


118 contr. 


IH contr. 


118 contr. 


26 


150 M3/s 


153 MB/s 


150 MB/s 


27 


15 MB/s 


15 MB/s 


15 MB/s 


28 


1 


1 


1 


29 


1 


1 


1 


30 


ISec. 7 
1 


ISec. 7 
1 


ISec. 7 
1 


31 

32 


1 Sec. 8 
1 


ISec. 8 
1 


ISec.8 

1 


33 

3<t 


ISec.8 


ISec.8 


ISec.8 


35 


1 


1 


1 


36 


1 


1 


1 


37 


IAPP.0 


IAPP.0 


IAPP.0 


33 


1 


1 


i 


39 


ISec.8 


ISec.8 


ISec.8 


%0 


1 


1 


1 


Si 


1 


1 


1 


H2 


ISec.8 


IS*c«8 


ISec.8 


*3 


1 


1 


1 


SU 


ISec.8 


ISec.8 


ISec.8 


*5 
Sb 
ST 

sn 

%9 
50 
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12.0 APPENDICES 

12. Z APPENDIX 8 - CYBER 180 SYSTEM DESIGN OBJECTIVES 



Glossary for CYBER 180 System Objectives 



SCHEOUIE/MILESTONES 



TARGET LEASE RANGE 



NO. OF CPU'S 



NO. HEMORY PORTS 



MEMORY SIZE 



MEMORY INTERLEAVE 



RECONFIGURE BY HAROWARE 



RECONFIGURE BY SOFTWARE 



CONCURRENT I/O 



The quarter In which pre-production 
systems are delivered to controlled 
customer installations. 

The Auerbach lease range to be covered 

by the systenw including maintenance and 
software. 

System software will support hardware 
configurations with this range of like 
central processors. 

Number of memory ports available for 
CPU* IOU» ECS or Common memory. 

The range of central memory capacity 
that can be configured Into the system. 
Note that the maximum capacities are 
required only for large dual -CPU systems 
and can be satisfied with two memory 
units. 

The number of individually cycl3bte 
memory modules over which 6* bit word 
addresses are sequentially assigned to 
assist in randomizing accesses to those 
modules. 



Hardware capability to 
around memory failures. 



reconf igure 



I/O BANDWIOTH 



MAX. PERIPHERAL RATE 



The page sizes of memory that can be 

maooed out of use by software to 

minimise the effects of error 
conditions. 

The number of peripheral controllers or 
communications controllers that can be 
operating concurrently under system 
software control. 

The maximum I/O bandwidth that the 
system must support in simultaneous 
transfers to or from I/O devices. 

The highest instantaneous transfer r3te 
from a- single peripheral that will be 
supported by the system. 



1 
Z 
3 

H 

5 

6 

7 

8 

9 

10 

11 

12 

13 

Ik 

15 

16 

it 

18 

19 
20 
21 
22 
23 
2<* 
25 
26 
Zf 
28 
29 
30 
31 
32 
33 
3<i 
35 
36 
37 
38 
39 
%0 
VI 
HZ 
US 

<!<♦ 

«i5 
«*6 

<i8 
<i9 

50 



SYSTEM PERFORMANCE 

SYSTEM RELIABILITY 
SYSTEM AVAILABILITY 
MANUFACTURING COST 



System performance ob|ectives and 
benchmarks- 
System MTBI er\d MLT Objectives. 
System Availability objectives. 

System and. component manufacturing 
costs. 



SYSTEM MAINTENANCE COST System and comoonent maintenance costs 
FC0 RATE 



PSR RATE 



Field change order objectives for 
hsrdnare. 

Software maintenance cost objectives. 



1 
2 
3 

W 
5 
6 
7 
* 

9 

10 
11 
12 
13 
!<♦ 
15 
16 

ir 
is 

19 

20 

21 

22 

23 

2h . 

2"5 

26 

?r 

25 
29 
30 
31 
3? 
3 5 

J* 

35 . 

36 

3/ 

38 

39 

VO 

Si 

V2 

«*3 

Uk 

«5 

*b 

«•/ 

•»* 

«i9 

50 
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12.0 APPENDICES 
12.3 (#! APPENOIX C 



PERIPHERALS SUPPORTED AND COSTS 



12. 3 ifJL^E£EN.Qi2L£_^F^l£Hi;R^^ 

"Supoorted CYBER 170 O.S." means supported by NOS or NOS/BE 
software. 

-Supported CYBER 180 O.S." means supported by N0S/80. Hhere a 
product Is supported In both states, the CYBER 170 channel and 
uncodified controller Is used for CYBER 180 state. Changes In 
controlware and recording format are not precluded. 

Manufacturing costs are for 1980. If the equipment Is In 
production now, the cost Is based on the present standard 
manufacturing cost. For new equipment, the cost is an estimate 
by the appropriate development organization. 



PERIPHERAL EQUIPMENT * CONTROLLERS 



MASS STORAGE EQUIPMENT 

8fl5 Fixed Module Disk Drive tFMDI 
(two spindles) 



FMO/8^ Disk Controller 17155-X! 
(Serial Recording) CC170 Channel! 

FM0/fl<^ Disk Controller 
(Serial I Parallel Recording) 
(C180 Channel! 

8<»<»-<»X Oisk Orive 



8«»<i-«iX Oisk Controller <7m-X! 

819 Oisk Orive 

819 Disk Controller 



I SUPPORTED 
COST I CYBER 170 
I O.S. 



I 

I 

I 

1*»800 I Serial 

IRecording 
I 



Yes 



I 
I 
9000 I 
I 
I 
9000 I Yes* 
I 
I 
I 

I 
I 

1*000 I 

I 
I 

I 
I 

I 

• f- 



6100 



tbf 



tbf 



Yes 



Ye» 



NO 



No 



SUPPORTED 

CYBER 130 

O.S. 



Serial 
(Rl! 1 
Para! lei 
(Rll 

Recording 

Yes 
CR11 

Yes 
(R2) 



Yes 
<Ri! 

Yes 
IR1! 

No 

No 



* THETA/170 only. 
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12.0 APPENDICES 

12.3 f#) APPENDIX C - PERIPHERALS SUPPORTED ANO COSTS 



+..... — -_ — .... ...... ....-.+... i 

IPERIPHERAL EQUIPMENT 1 CONTROLLERS! COST 


.................... 

SUPPORTEOI SUPPORTED 

CY°HR 17 31 CYBER 180 

O.S. 1 O.S, 


IMAGNETIC TAPE EQUIPMENT ! 


r 7 








1 66X Tape Orive 


12000 


Yes 




Yes 
(R2) 


1 66X Tape Controller (7021-21,-22) 


11500 


Yes 




Yes 
, (*?'2! 


1 67x Tape Orive 


10000 


Yes 




Yes 
(«i» 


1 67X Tape Controller (7021-3X1 


11100 


Yes 




Yes 
(Ri! 


1 MSS Tape Library 

f (includes controller! 


130000 


Yes 




No 


1 MSS Tape Library 1 
1 (Second Generation! 


TBF 


No 




. Yes 
(T30) 


•PRINTER EQUIPMENT 










1 580-12,-16,-20 Printer 
1 (1200,1600,2000 Ipm! 
1 (Includes controller! 


21500 


Yes 


3 
C 
5 

3 
3 

8 
8 

8" 
8 
8 
8 
8 
8 

8 


Yes 

(R2I 


1 580-120,-160,-200 Printer 
1 (1200, 1600, 2000 IdriI 
1 (includes controller! 


21500 


Yes 


Yes 
(R2) 


1 596 Train 


17t*0 


Yes 


Yes 
IR2! 


1 Non-impact Printer (8000 Ipm! 
1 (includes C170 controller! 


20600 


Yes 


Yes 
(R2) 


1 Non-impact Printer (8000 Ipm! 
1 (Includes C180 controller! 


27100 


No 


Yes 
1*31 


1 Non-impact Printer (20000 Ipm! 


tbt 


No 


Yes 

CTBO! 
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12*0 APPENOICES 

12.3 (a) APPENOIX C - PERIPHERALS SUPPORTED AN!} COSTS 



«.-* — ••» — ••- — — —« — •••••• «»^ 

PERIPHERAL EQUIPMENT I CONTROLLERS 


► •- ——— 4 
COST 


SUPPORTED 

CYBER 1701 

O.S. 1 


h-—- .-- — 

SUPPORTED 

CVBER 180 

. O.S. 


CARD EQUIPMENT 








405 Card Reader 11200 cpmf 


16200 


Yes 


Yes 
tR2> 


405 Card Reader Controller • 


4500 


1 Yes 


Yes 


415 Card Punch C250 com! 

(includes 3446/3644 controller! 


20500 


! Yes 


No 


MISCELLANEOUS EQUIPMENT 








12 lines 

20 lines 

100 tines 


1 37000 
1 41000 
1 105000 






2551-1,-2 Communication Coritr. 


tbf 


Yes 


1 Y«s 
1 IR2I 


752-10 Display/keyboard 
(as consolel 


1000 


No 


1 ' Yes 
I (R2>» 


CC545 OIspI ay/keyboard Console 


7700 


Y«S 


IR2) 


6681-2 Data Channel Converter 

1 channel 

2 channels 

3 channels 

4 channels 


i moo 

1 6400 
1 8700 
1 11000 


Yes 


Yes 
CR2I 


6683 Channel Couoler 


I tbf 


Y<§s 


Yes 

1 1*2-180/ 

11701 

KR3-180/ 


OATCM TERMINAL EQUIPMENT 








CY9ER 18-5 Batch Terminal 


19000 


f Yes 


1 Yes 
!R2> 



1 

2 
3 

4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
1% 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3V 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
<»6 
47 
48 
49 
50 



1 • 


1829-60 Card Reader (600 coml 




1 Yes t 


Y«!S 

(R2» 




1827-600 Band Printer (600lDm) 




1 Y«s 


1 Yes 
(*2> 




Card Punch (lOOcDml 


t,bf 


1 Yes 


Yes 


♦— 






-f ------ 


1 (R2> 
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* Supported at Rl for debug facility. 

12.3.1 TERMINALS SUPPORT tAPP.CI 

The following terminals are supported by Network Products In 
CYBER 170 and CYBER 180 states! 

CDC 200 UT, 214, 217, 731-12, 732-12, 734-1 

COC 711-10 with option 102-Data Control 

COC 714 except for impact prlnter/non-impact orinter 

COC CY18-XK as 200 UT, 2780/3780, or HASP multi-leaving 
• terminal ... 

COC 713-10, 751, 752, 756 

TTY M33, M35, M37, M38, MV0 

IBM 2741 IEBCOIC or Correspondence! - with Transmit and 
Receive Interrupt features 

IBM 2780/3780 

inM 360/20 as a HASP multi-leaving terminal 

IBM 3270 

Tektronix 4010, 40 It, 4013 

Hazeltine 2000 

GSI 300, 300Q 

OEC writer II 

Anderson-Jacobson 803 with Diablo whe*! 

HARRIS 1200 HASP mul ti- leaving terminal 

COMPANY PRIVATE ORAFT 
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DATA100 78 HASP mut t 1- I eavlng terminal 

C18 based Full Duplex Batch terminal 

Commonly used future terminals 

These terminals are support ad using the COC Mode %♦ HASP* Bleary 
synchronous and asynchronous tint protocols. The APL character 
set is supported on those terminals which offer It as an option* 
New terminal developments needed In industries In which CYBER 160 
Is marketed will be supported. 

In addition* the network provides the basis for 'an Interface 
to Value Added Networks (VANsI* such as TELENET* OATAPAC and 
TRANSPAC* using the X.25 communications protocol. Support is 
provided for a subset of X.25 consisting of Level It Level 2 and 
the Permanent Virtual Circuits only of Level 3. It is the Intent 
to track standardization activities In this area and implement to 
the standards as they evolve. 
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5 

I 6 
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10 

111 

112 

13 

tl<» 

115 

116 

117 

118 

119 

120 

21 

22! 

23 

Zh 

25 

26 

27 
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33 
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12. «. Iii^^BE£riiiIXJ3^i.SISItd-aatlEI& , iSAIIQHS-.^QLJ:Q5Li 



The configuration assumptions and component characteristics 
were used as the base to calculate the RAi objectives* 
Performance Objectives, and Cost Objectives. 

&£pacal..Sfc(iiar.Iis. 

• The system configurations shown are representative 
systems. Optimal configuration for each Installation* as 
a function of its application environment. may deviate 
significantly from the typical system, 

• Only s.lD-3lfi. mainframe' system configurations are Included 
at this timet multi-mainframe configurations will be 
added. 

• New peripheral products* e.g.* Mass Storage Subsystem* 
non-laoact printer* helical scin t3pest swapping 
memory*etc. will be included as design specifications 
become firm. 

• Entry system is defined as the minimum , system to run 
production. Target system is one that runs a 'full 
production load reliably* and is the one against which 
objectives 'wil I be measured. Large system Is defined as a 
dual-CPU system with representative supporting 
components. The target systems have been configured to 
maximize reliability regardless of cost* For example* 
they contain MG sets with 2 1/2 second ride-throu?h 
capabilities as opposed to the entry end large system 
which do not. 

« Mainframe costs are based on the assumptions given In 
11. l f and peripheral costs are based on those given in 
Appendix C. 

. The power requirements tor an individual system must be 
assessed for that system. The ratings of the MG-sats 
specified for "entry*'* "target** 3nd "large" systems have 
been calculated for those specific configurations. 
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-♦ — — 






1 








1 








1 


IS1 SYSTEM/C180 STATE 

1 


! ENTRY 


1 
1 




TARGET 


1 

1 




LARGE 1 
1 


ICOMPONENT 


IQUANTIMFG 


COSTIQUANTIMFG COSTIQUANTIMFG 


COSTI 


1 Processor 


1 1 1 




75300 


1 


1 


1 


87800 


1 


2 


1 


155800 1 


1 


1 1 






1 




1 




1 




1 




1 


IMemory 


1 1MB 1 


(1 


IClJ 


1 


2KB 


1 


flncl.l 


1 


«»NB 


1 


Unci.) 1 


» 


1 1 






1 




1 




1 




1 




1 


II/O Unit 


1 1 


Ci 


nc 1 .) 


1 




1 


flncl.l 


I 




1 


flncl.l 1 


1 -PP'S 


1 5 1 






1 


10 


1 




1 


10 


1 




1 


f -I/O Channels 


1 9 1 






1 


10 


1 




1 


12 


1 
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1 


3 


1 




1 


3 


1 




1 


! -Two Port Mulitplexer 
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i t 
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■ 


1 


1 

t 
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1 
1 

1 


.1 


1 
1 

1 




500 t 

1 

9000 1 


ISystem Power 


1 1 1 




7%00 


1 


1 


1 


13000 
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1 
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1 


IPower Control Panel 
i 


1 1 1 
1 1 
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i 


1 
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i 
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i 


1 


1 
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1 




2000 t 
i 


•Environment Monitor 






t 


1 


1 
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,1 
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I 108300 I 



I 172300 t 
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I 

IS1 SYSTEM/C180 STATE 

I 



ICOMPONENT 



IFixed Module OlsK Drive 

I (Two Spindles/Module) 

I 

IS^-^X Disk Drive 

I 

IFMD/8<»«f Dl sK Controller 

I 

I67X Tape Drive 

I 

I67X Tape Controller 

I (7021-3X1 

I 

16681-2 Dat8 Channel 

I Converter 

I 

1^05 Card Reader/Ctr 

I 

1580-20 Line Printer 

I 

ICYBER 18-5 Batch Terminal 

1 600 lorn Band Printer 

I 600 com Card Reader 

I 

I255X Comm. Front End 

I - Communication Lines 

I 

1752-10 System Console 

I 

ICC5*i5 System Console/Ctr 



IPERIPHERAL COST 



1 TOTAL COST 



ENTRY 



QUANT t MFG COST 



1 
12 



12200 
9000 



19000 



37000 
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78200 



16M00 



IRMS STORAGE BILLION BYTES! 0..* 
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TARGET 



LARGE 



QUAN^IHFG COSTIQUANTIMFG COST 



2 
112 



1<*800 

12200 
18000 
30000 
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38000 



105000 



1000 



I 

I 
I 
I 
I 
I 
I 

1 

I 

I 

1 

I 

I 

I 

I 

1 

I 

I 

I 

I I 

I t 

I I 

I 2 I 

I 112 I 

I t 

I t 

I I 

I 1 I 



230100 



339100 



29600 

2«*<»00 
18000 
60000 
22200 

M00 
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21500 



105000 
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313500 
*»865QQ 
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I 3.2 I 



Notei System costs are based on assumptions qlven in 11.1 
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1 
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1 
t 
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t 

1 




LARGE t 
1 


COMPONENT 1 


QUANTIMFG COSTI QUANT 1MFG COSTIQUANT t MFG COST! 


Processor 


1 


1 
1 


72000 


1 
1 


1 


1 
1 


72000 


1 

1 


2 


1 
1 


1M»000 1 

1 


Memory 


1MB 


1 


72000 


1 

1 


«iHB 


I 
1 


89000 


1 
1 


8MB 


1 

1 


130000 1 
1 


I/O Unit 


1 


1 


•vrooo 


t 


1 


I 


51500 


I 


1 


1 


59000 1 


~PP«S 


5 


t 




t 


10 


1 




1 


15 


1 


t 


•I/O Channels 1 


6 


1 




1 


10 


1 




1 


16 


1 


1 


-Maintenance Channels 


1 2 


I 




1 


u 


1 


700 


1 


«• 


1 


700 1 


-Two Port Multiplexer 


1 1 


1 




1 


1 


I 




1 


1 


1 


1 






1 




1 




I 




1 




1 


1 


System Power 


1 1 


t 


9000 


1 


1 


1 


13000 


1 


1 


1 


13000 1 






1 




1 




1 




1 




1 


1 


Power Control Panel 


1 1 


1 
l 


zroo 


1 
i 


1 


1 

I 

1 


2700 


1 


1 


1 
1 
1 


2700 1 


Environment Monitor 




i 




1 


1 
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1 


1 


5000 1 



MAINFRAME COST 



I 202700 t 
.4.— — .—--*« 



I 233900 I 



I 339<»00 I 



2 

2 
2 

12 
2 
2 
2 
2 
2 

12 
3 
3 
3 
3 
3 
3 
3 
3 
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I 

IS2 SYSTEM/C180 STATE 

I 



ICOMPONENT 



IFlxed Module DlsK Drive 

I (Two Splndles/ModuU* 

I 

!8<»«»-«fX Dish Orlve 

I 

IFMO/8^% Disk Controller 

I 

I67X Tape Drive 

I 

I67X Tape Control ler 

I 

16681-2 Data Channel 

I Converter 

I 

K05 Card Reader/Ctr 

I 

1580-20 Line Printer 

I ' ■ 

INIP - 8000 Ipm (C1801 

I 

ICY3ER 18-5 Batch Terminal 

I 600 low Bend Printer 

I 600 cpm Reader 

I 

I255X Corn*, Front End 

t - Communication Lines 

I 

1752-10 System Console 

I 

ICC5%5 System Consolt/Ctr 



IPERIPHERAL COST 



I TOTAL COST 



1RMS STORAGE BILLION BYTES 
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QUANTIMFG COST 



1 
12 



O.tt 



12200 

9000 
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11100 



19000 

37000 
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109300 



312000 
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2 
112 



1.8 



MFG COST 



1<»800 
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18000 
<*0000 
11100 
MOO 

20700 
21500 



105000 
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262000 



<»95900 



LARGE 



QUANTIMFG COST 



% I 

I 

I 
6 I 

I 
«♦ I 

I 
8 I 

I 
2 I 

I 

1 I 
I 
I 

2 I 
I 

1 I 
I 

•II 
I 
I 
I 
I 
I 

2 I 
112 I 

I 

I 

I 

1 I 



51200 

36600 
36000 
80000 
22200 
<»100 

<tU00 
21500 
27100 



105000 



8500 



I <»«»1600 



I 781000 



6.0 I 



•• Packaging - The Initial ENTRY and TARGET systems have 3 seoarate 
cabinets *CPU t Memory, I3UI costing an estimate! $60-75,000 of 
mainframe* It Is a reaulreraent that subseouent packaging redesign 
accommodate these configurations In a manner which saves S25tOQ3. 
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IS3 SYSTEH/C160 STATE 
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if 
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IProcessor 

I 16K Byte Cache Increment 

I 

IMemory 

t 

11/0 Unit 

1 -PP*S 
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I -Two Port Multiplexer 

I 
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I 
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4 
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I 

I 
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I 
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10 

2 
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I 
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I 
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I f 
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I 
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I 
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I 
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I 
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I 
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I 
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I 
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I 

I 

I 

I 

t 
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I 
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I 
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IS3 SYSTEM/C180 STATE 1 
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ITHETA SYSTEM/C180 STATE 
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« 
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I. 
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I 
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I 

1 
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1 
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1 Processor 
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• 2 
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8MB 
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16MB! 
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1 1 

ITHETA SYSTEM/C180 STATE t E 
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:ntry 


1 

1 


• 


TARGET 


I 
1 
1 




LARGE 


1 

1 


tCOMPONENT 1 QUANT 1 


MFC COSTIQUANTIMFG COSTIQUANTI MFG COSTI 


IFIxtd Module Drivo 1 3 


iihi+QQ 


1 


7 


I 


103600 


I 


12 


1 


177600 


1 


1 (t* rte3d Parallel! 1 1 
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1 
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1 
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1 
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1 6<4«*-«fX Olsh Drive 1 h 
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• 
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72000 
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I67X Taoe Drive 1 «♦ 
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1 
1 


6 


t 


80000 


1 
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1 


l**05 Card Reader/Ctr 1 1 


1 20700 


1 


2 
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t 
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1 


2 


1 
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I 


1560-20 Line Printer 1 1 
I 1 


21500 


1 

1 


2 


1 
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1 
1 
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1 
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1 
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Notei System costs are based on assumptions given In 11.1* 
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1.2.5 JBEEEmiX-E - SHIPMENT .EQS^S&SIS 



The following data is based on the CYBER 180 Product Life 
Forecast by O.L.Mueller and B.L. Thompson! dated April 1*»» 1978. 
The figures are for system acceptances. Including both new builds 
and returned systems. Reconciliation with previous forocasts are 
as tot lows! 

Model 820 was formerly the SI. 

Model 8*»0 was formerly the S2. 

Model 850 was formerly the S3. 

Model 860 Is a new -model* not yet defined In AO/R. 

Model 870 was formerly the C-178 and S<*. now THETA. 

Model 880 was formerly the S5» not yet defined in AO/R. 
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12. 6 iJPJEEHOIX-E,' CY9ESUM^Q£^gQ£a&liLJiIl£SIflH£S 



SI 5YSTEN 

-Release of SI (CYBER 170 statel 

(First preoroductlon SI shipment! 
-First external user shipment of SI 

-Release of Si (CYBER 100 state! 



-Release of S2 (CYBER 170 state) 
(First preproductlon S2 shipment! 

-Release of S2 (CYBER 180 statel 



SXJ3*£I£M 

-Release of S3 (CYBER 170 statel 
(First preproduct ion S3 shipment! 

-Release of S3 (CYBER 180 statel 



-Release of THETA (CYBER 170 statel 
(First oreproductlon THETA shipment! 

-Release of THETA (CYBER 180 statel 



-Operating System 1 Product Set Released 
•Phase 1 (OS, FTN, COBOLt SORT! 
.Phase 2 (Additional Features/Products) 
•Phase 3 (All AO/R requirements! 



12/19/80 

03/15/81 

03/31/82 
(est.! 

01/15/80 
12/01/81 

11/01/80 
03/31/82 

T8F 
TBF 



12/01/81 
0<i/01/83 
12/01/8<» 



These development milestones were approved by the CYBER 180 
Baseline Change Control Board on December 16* 1977. It is tha 
objective of the CYBER l6"0 program to meet these schedules. 
Check the Program Plan, Section 3# and Appendixes A and B for the 
most current schedule. 
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12.7 l.f>,.,ABEEKaiaL& - fH££AHQ£i,ACUaN_£LAtl 



12.7.1 MIGRATION ALTERNATIVES 



This section describes a few of the reasonable alternatives 
for irigration and some of their advantages and limitations. Each 
alternative is considered as though It were the only one 
selected. The next section sets forth the recommended migration 
path for CDC and its customers. 
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II Least direct cost to CDC. 



2! Must be done at some 

level for any alternative. 



LJLql Li. allans 

II Lowest appearance of user 
support 



12. 7. 1.2 £QjiLiian..Pr.o<Jucls^flDj[/ttCL.ltilftc.liacji5^iA£Exfil 



In this alternative maximum emphasis is placed on the 
development of common products between CYBER 170 and CYBER 180^ 
This Is referred to as "banding". A product may be either a 
software product (both product set and applications! or a 
hardware product- Wherever common products are not practical 
then a common product Interface Is enforce! between the sebarate 
implementations. Again the expectation Is that customer/users 
will begin to bend towards CYBER 180 like products on CYBER 170* 
This can be encouraged byl pricing actions, feature enhancement. 
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12.0 APPENOICES 

12.7.1.2 Common Products end/or Interfaces CAPP.GI 
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12-0 APPENDICES 

12.7.1o*» Dual State Processing lAPP.G) 



etc • 

1) Presents the simplest path 
for user conversion. 



II Maximum impact on current 
CYBER 170 Product 
development. 

21 Users may not follow the 
bending. 

31 CYBER 180 products may not 
perform at maximum efficiency 
due to CYBER 170 orientation* 



12. r. 1.3 cjmv.ansloj3jLojas_aQd_&£cy.lc.£s 



A comprehensive set of tools and services are provided by CDC 
to assist users In their conversion efforts. 



II Indicates support 
by CDC for the user 
conversion problems. 



2) For simple cases of 

conversion such tools art 
very effect lve« 



LimitailftQS 

II Such tools are, very difficult 
to produce when both ends of 
the conversion process are 
changing* 

21 development of conversion 
tools Is expensive* Unless 
carefully selected* they 
9P9 only of short 
term value* 

3t General ourpose conversion 

tools are often more difficult 
to use than simply writing 
a specific conversion 

program, 

«il It Is very difficult to 
determine which situations 
warrant conversion and In 
what order tools should be 
produced* 
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12.7. !.<# flmf State Processing (APP.G) 



A single CY3ER 180 system can execute both CY9 
160 fobs. CY9ER 180 du3l state ooeratipn is prov 
partition control and co-nminl cat Ion control bet 
CY170 environments. Oual state processing wi 
extensions to Symmetric LlnK capaoilities b*ing n 
and N0S/1E. The capabilities will allow lnterc 
and NCS/BE software operating in CY17C mainframe 
state of CY130 with NOS/1B0 software. Toth 
program level control is provided in cjth batch 
modes. This orovides permanent fil^ . an 
transmission between states* submission of |obs 
and linkage to both COC provided and user deve 
and reformatting routines. This caoaolllty v> I 
provide for record conversion and reformatti 
migration frem CYlfO state to CY19C state* Note 
does not eliminate tne conversion oroblem It 
time period within which conversion can t ike o 
state support Is provided Indefinitely some 
never take place* 
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Asteajilaafis 

1) Allows customer/user choice 
as to when conversion of 

a particular jobt program 
or file will take place. 

2) An Industry accepted 
migration path. 



LiQULlallims. 

II Performance degradation 
relative to pure CYBER 170 
or CYBER 180 state. 



21 Increased hardware costs* 



31 Requires COC maintenance 

support for CY9ER 170 oroducts 
for an extended time period. 



12. /.2 MIGRATION ACTION PLAN CAPP.G) 



The recommended solution for COC and customer migration to 
CYBER 180 Is a combination of all of th* previous mentioned 
alternatives with specific techniques for each aspect of system 
usage. Although all alternatives are equally Important* emphasis 
wllf be placed on common products* conversion aids and dual state 
processing. 



The timeframe for accomplishing the ma|or 
Hlgratlon Action Plan Is expected to bet 
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12.7.2 MIGRATION ACTION PLAN IAPP.G! 
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12.0 APPENDICES 

12.7.2.2 Customer/User Conversion CAPP.G1 



Migration Plan Approved - ADIC 

Conversion Action Plan - Draft 

Hlgratlon Plan as oart of CU80 A0/R f 
Rev.C - submitted for Company approval 

Migration Plan as part of CY170 AO/R - 

Submitted for Company approval 

Training Plan - PLH Approved 

Start Training Implementation Plan 

Conversion Action Plan - Approved 

Conversion Aids GOS - A01C Approved 

Migration developments (i.e.* tools* aids* 
conversion programs! defined in 
N0S-N0S/8E R5 ♦ OR*s 

Conversion Aids User Guide 

12.^.2.1 fctnecal 



«i/3/78 

%/28/78 

672/78 

10/78 

TBO 

TBO 

10/78 

10/78 

TBO 

2079 



II Training 



no single activity is more 
Important than training. All 
people within COC systems 
buslnesst software vendors, and 
the customer base must be trained 
in CYBER 180 processing 
operations. training can be done 
on both a formal te.g.* classes. 
PLATO documents) and Informal 
(e.g.* Dress releases* strategy 
documents! basis. 

Training will be regulated by 
Product tine Management and New 
Product Programs so as io assure 
correctness* continuity and 
consistency. 
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12.7.2.2 CtUSlttflimZUsgr. CtaDy.gLCSl&Q-lAEE.i&I 



This section defines the specific actions to bn taken for 
various aspects of customer/user conversion. The acHon 
descriptions are grouped into the four conversion areas defined 
previously under "Conversion" and are further dlvidtd Into 
specific areas of concern within each group. A set of solution 
act Ions are defined* In priority order* for each area of concern 
(e.g.. Source programs!. Th9 actions stated are limited to those 
previously described under "Migration Alternatives". 

12.7.2.2.1 PROCESSING OPERATIONS (APP.G! 



II Source programs 



- Common Source Language Standards 

- Common Products {Compiler Front 
Ends! 

• Conversion Aids for FORTRAN* 
C00OLtBASIC*APL*ALGOL I PL/I 



2!0b)ect programs/libraries - Oual state execution 



31 Source .Libraries 

%IJob deck structure 
5IJob processing conceots 
6IUser Command Language 

71 Accounting/Bl I I Ing 

flj Ooerat ions 

9)Product Maintenance 
Procedures 

10)*?un time services 
111 Aopl leaf Ions 



- Common Products Ideveloo- 
ment tools! 

- Conversion Aids 

- Training 

- Dual state execution 

- Trailing 

- Oual state execution 

- Training 

- -Common Products 

- Dual state execution 

- Conversion Aids 

- Trailing 

- Training 

- Training 



- Training 

- Comnjn int^faces 

- .Common products 

- Common orcduc.ts 

- Comion interfaces 
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12.0 APPENDICES 

12. 7. 2,2,1 PROCESSING OPERATIONS IAPP.G! 
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12.0 APPENOICES 

12.7.2.2.5 CONVERSION ACTION PUN (APP.GI 



Training (both COC and vendor! 
Source Language and File 
Conversion Aids 



12.7.2.2.2 INFORMATION STORAGE 



llFltes 



2)Fi le Management 
Services 

3) Data Oases 



<*!Oevices/Media 



- Conversion Aids 

- Oual state execution 

- Common Interfaces 

- Training 

- Common Interfaces 

• Conversion Aids 

- Oual state execution 

- Common Products 

• Common Products lsubs«t of CYBER 
170 supported products! 

- Oual state execution 



12.7.2.2.3 HARDWARE FACILITIES 



1) Front-ends 
2) Terminals 

3)Non-CDC Hardware 



- Common products 

- Oual state execution 

- Common oroducts 

- Oual state execution 

- Training 

- PSD Contract 



12. 7.2.2. if HUMAN ANO ADMINISTRATIVE PROCEDURES 



DTormlnal Services 



2! Network Services 



31 Admlnistrat ion 

«»)User Control and 
Administration 

5) User Interfaces 



- Common products 

- Common Interfaces 

- Oual state execution 

- Common Interfaces 

- Common products 

- Oual state execution 

• Training 

• Common products 

• Training 

- Training Inhere not covered 
in other areas! 
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12.7.2.2.5 CONVERSION ACTION PLAN CAPP.G! 

The near term requirement of the Conversion Action Plan is to 
produce General Design Specifications of the conversion aids for 
the products to be provided with NOS/18 # Rl. These GDS documents 
will be collected Into one document to be used In support of 
training. Additionally, software publications for the CY170 
product s-et <CPS R7J will include recommended usages* i.e., 
f II est commands, etc. to reduce future conversion. 
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12. 7. 2. 2. 5 CONVERSION ACTION PUN (APP.GI 
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ACIUQliS 



B$liLa£e_i 

CY170 FORTRAN 5 to 

CY160 FORTRAN 5 
CY170 BASIC M to 

CY180 BASIC «• 
CY170 C090L 6 to 

CY180 COBOL 6 
SYMPL Conversion Aids 



RftSBgasibltltY 

R.Ragan 

J. El liott 

W.Hubrick/ 
O.Nelson 
L.Magee/ 
R.Ragan 



CY170 ALGOL to CY160 ALGOL R.Ragan/ 

J.Schl ichting 
CY170 APL to CY180 APL B.Pommers 



CY170 PL/I to CY180 PL/I 



B> LlifiS 



R.McAl tester 



W.Ceagt io 



Release % 

User Oata Files - CRM/BAM AAN 
C170 QAM to/from C180 8AM T.McGee 
-Sequential Sequential 
-Word Add. Byte Add. 
C170 AAM to/from C180 AAM 
-Index Seq. Index Seq. 
-Multi Index Multi Index 
-Oirect Access/Actual Key to 
Index Sequential R.Ragan 
PANMS - FORTRAN W.Hubrick/ 

Relative - COBOL O.Nelson 



o ILala-JteaagaaaQt 

COCS (relations! to OMS180 S*Radeliff« 

(sets) 
OMS170 Data Base to OMS 180S.Radct i f f 

Oata Base 
Query Update J.de laBeauJ ardlere 
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0) uilfitY...P(ittacai!i5 

Control Card/CCL Conv.Alds G.Nelson 
Update Conv.Alds B.Pommers 

Editor File Conv.Alds D.Elefson 
Permanent File Dump Conv. A i S. Fewer # 



E) cll^JLlQh&CRQt-.Q9nvgc.siaa 

Oual State - Linked File S. Fewer /G. MatHowl ts 

Conversion 
Dual State - ASCII to/from S.Fewer /G.Matkovi ts 

Display Code 
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12.7.2.3 SojLJLtta.r.g Produces 



This section is now included in Section 3.6 - Migration of the 
CY180 AO/R, Rev.C. 



12. 7.2. <♦ Spftware Product Phasing 



This section is now included in Section 6.0 - Product Phasing. 
Objectives or the CY180 AO/R Rev. C. 



12.7.3 MIGRATION ACTION LIST 



These product descriptions are grouped according to the 
migration alternatives that thev represent and define 
responsibilities in support of the Migration Plan. 

12.7.3.1 IcalDlPq (APP«.£L 



II A long term development strategy that can be presented! to 
all CDC system business employees external software 
vendors and to all customers. The migration activities 
set forth in this plan should be included* 

Responsibility! New Product Programs 

21 A training plan for Internal COC and external vendor use. 
It will be oriented to three levels of people? first? 
ml idle and top- management and will include technical? 
marketing, and business perspectives* 

Responsibility! Product Line Management 
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12,0 APPENDICES 

12.7.3.1 Training (APP.GI 



3) For each ar«a where training is specifically calUd out a 
training guide Hill be produced. The guide will contain 
two major types of information! II variances between CYBER 
170 and CYBER 180 f and 2) lists of both CYBER. 170 and 
CYBER 190 reference manuals that describe the affected 
ores. 

ResDonslbil ltyt Product development groups 

12. 7.3.2 HttinnifllD,PXflfitu£ia_l[lIflER_17fl and CYBER 18?) 

1) Compiler front-ends for FORTRAN, COBOL* SYHPL, ALGOL and 
BASIC flf compiler is usedl. 

Responsibility! Sunnyvale System Oeslgn 

21 Source code maintenance utilities (I.e., Update!. 

Responsibility! SES Development 

3> User Command Language processor. This product will not 
replace the NOS/BE or NOS products but will augment them 
so as to allow gradual user conversion on CYBER 170. 

Responsibility! CYOER 130 System Oeslgn 

41 At I application products. Operating System requirements 
to ease migration of applications. 

Responsibility! AP*0 and Application Resource Center 

51 Configuration Control, Peripheral Devices and Media will 
be able to be attached to both CYBER 170 and CYBER 150 
mainframes. Firmware will be common where practical. 
Communication front-ends will be able to be attached to 
both CYBER 170 and CYBER 180 simultaneously. Terminals 
can select connection. 

Responsibility! Archltectual Oeslgn I Control 

61 Terminal services products such as editors, formatters, 
and Information aids. 

Responsibility! CYBER 180 System Design 
71 Network products. 

Responsibility! CYBER 180 System Design and Sunnyvale 
System Oeslgn 



12.0 APPENDICES 

12.7.3*3 Common Interfaces tAPP.G) 
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1^.7.3.3 £flmniaQ^lDJ.aniftC2LSL.UEE«.!iL 

II Gourci languages shall have common external soecl tf icat Ions 
fbr CYBER 170 and CTBER 180 covering the majority of the 
language definition* System or rfachlne dependent features 
will be minimized. 

Responsibility! Sunnyvale System Design 

2) Run time services II. e.. Loader. M8th Science Library! 
will be equivalent In capability and will have common 
Interfaces where . pr3Ct leal . 

Responsibility! CYBER 180 System Oeslgn 
Sunnyvale System Design 

3) Application codes that cannot be Implemented as common 
products will present a common user interface. 

Responsibility! CYBER 180 System Oeslgn .and Application 
Software Development 

41 File management services will be functionally upwards 
compatible from NOS. . . 

Responsibility! CY3ER 130 System Design 
5) Oata base management services. 

Responsibility! Sunnyvale System Design 
6} Terminal services. 

Responsibility! CYBER 180 System Design 
71 Network services. 

Responsibility! CYBER 180 System Oeslgn 

12. 7.3.4 Ctg D y ft QsiflQj^Qis^aiid^Si&iiy.lc.tts., ( APPt G) 



1> FORTRAN, COBOL, ALGOL, BASIC, PL/I and APL source language 
translators, as required. 

Responsibility! Sunnyvale System Oeslgn 

2) Oats file translators for files that contain well defined 
record structures. In particular, alt character, all 
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12.7.3.* Conversion Tools and Services IAPP.GJ 
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12.0 APPENDICES 

12.8 APPENDIX H - STANDARDS 



Integer or all real data or a mixture of those types In a 
fixed format within each and every record* These 
translators may ooerate as standalone utilities or as 
on-the-Hy translation routines. 

Resoonslbil ityi Sunnyvale System Design 
CYBER 130 System Oeslgn 

31 Conversion subroutines that users may include in th«lr 
orograms to convert lore complex file situations* 

Responsibility! Sunnyvale System Oeslgn 

<♦> Data base translators for both schema def init ions and data 
contents* 

Responsibility! Sunnyvale System Design 

I2«r.3.5 DjiM^ataJU-Ecacftssiag 

II At a minimum a means to concurrently execute CYBER 170 NOS 
and NOS/BE Jobs and 3YBER 180 |obs« 

Responsibility! CYBER 180 System Oeslgn 

21 Communication and network oriented users nay submit Jobs 
to either system although the communication hardware may 
only be connected to one operating system. 

Responsibility! CYBER 180 System Design 
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12.8 AEPJ&MDI^tt^JSLIAHafltRQS 



CYBER 180 systems will comply with the standards indicated in 
the attached master CDC Standards ChecKlist. Standards 
definitely not apDllcabte are marKed !-'NA'*. Those left unna^Ked 
In the categories of Codes* Data Reoresent at lon« Data 
Communication Keyboards* Cnaracter Recognition and various *edla 
are relative to NetworK Products and oerloh«?rai igvlces and jre 
applicable to the appropriate Implementing divisions* 

Product Design Requirements CO*) will Induie a COC Standards 
ChocHllst calling out those standards applicable to that 
particular productt in compliance with this master checklist* 
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CDC STANDARDS CHECKLIST (REV. E) 



TITLE 


Available 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chosen 
See 2.3 


Waiver 
See 2.4 


Verify/ 
Certify 
See 2.5 


Category - CODES 














Code for Information Interchange 
Cede fcr'lnfornjtirn Interchange 
?-Eit Coded Character Set for 

Information Processing Interchange 


ANSI X3.4 
FIPS PUB 1 

ISO 646 


X3.M 
PUB 1 








Implc:.--ntatiori of the Code for 

Information Interchange and Related 
Media Standards 


FIPS PUB 7 


PUB 7 








Code Intension Techniques for Use With 

Th.> 7-Dit Coded Character Set of 

ASCII 
Code Extension Techniques In 7 or 

G Bits 
Code Extension Techniques for Use With 

Tne 7-3it Coded Character Set 


ANSI X3.41 
FIPS PUB 35 
ISO 2022 


X3-M1 
PUB 35 








Control. Data Subset of ASCII 
"Subsets cf the Standard Code for 
Information Interchange 


1.10.003 
FIPS TUB 15 


1-10-003 








Perforated Tape Code for Information 

Interchange 
Perforated Tape Code for Information 

Interchange 
Representation of 6 and 7-Dit Coded 

Character Sets on Punched Tape 


ANSI X3.6 
FIPS PUB 2 
ISO 1113 


NA 
NA 
MA 








Hollerith Punched- Card Code 
Hollciith Punched Card Cede 
Representation of the 7-Mt Coded 

Character Set on 12-Row Punched 

Cards 
Representation of 8-Bit Patterns 

on 12-Row Punched Cards 


ANSI X3.26 
FIPS PUB 14 

ISO 1679 
ISO/R 2021 


X3-8b 
PUB m 








Representation of Numbers in Packed 
Deci...al Form 


1.10.016 


1.10. 01k 








Representation of Numeric Values In 
Character Strings for 
Information Interchange 


ANSI X3.42 


X3.M5 








Category - PAPER CARD MEDIA 




NA 








, 


General Purpose Paper Cards and Punched 

Mole Requirement:! 
80-column Card Files for Information 

in! "r chanje 


l.ia.ooe 

1.10.009 











•The standard has selectable options 



.'•ily 1077 



a-dsh 



CDC £7.\XD.\r.DS CilKCilLIf.T (i:EV. E) 



TITLE 


Aval 1 'rhic. 


Applicable 

F,tc '.,-irds 
So. ?.2 


Option 
Chor.cn 
See 2.3 


Waive r 
See 2.4 


V'.-riiy/ 

C'.itify 
See 2.5 


Category - PAPER TAPS MEDIA 




NA 










Eleven-Sixteenth Inch Perforated Paper 

Tape for Interchange 
Onc-In^h Perforated Par or Tape for 

Information Interchange 
One- Inch Perforated Paper Tape for 

Information Interchange 
Dimensions oi Punched Paper Tape for 

Information Interchange 


.\NSI X3.19 
ANSI XI. 16 
PIPS Pl'B 2G 
TSO 1154 










Take-Up Reels for One-Inch Perforated 

Paper Tape for Information 

Interchange 
Take-Up Reels for One- Inch Perforated 

Paper Tape for Information 

Interchange 


ANSI X3.20 
TIPS PUiJ 27 










Specifications for Properties of 

Unpunched Oiled Paper Perforator 
Tape 

Properties of Unpunched Paper Tape 


AESI X3.29 
ISO 1729 










Interchange Rolls of Perforated Paper 
Tape for Information Interchange 

Data Interchange on Rolled Up 
Paper Tape 


ANSI X3.34 
ISO 2195 










Category - MAGNETIC CASSETTE/CARTRIDGE MED1/ 




NA 










Implementation of the 7-Bit Coded 

Character Set and its 7-Bit and 8-Rit 
Extensions on 3.81 mm Magnetic Tape 
Cassettes for Information Interchange 

3.81 mm Magnetic Tape Cassette for 
Information Interchange 


ISO 3275 
ISO 3407 










Category - MAGNETIC TAPE MEDIA 




NA 










Recorded Magnetic Tape, 0.50 Inch, 

9-track, eoO CPI, NRZI 
Recorded Magnetic Tape, 0.50 Inch, 

-9-Tiack, 1600 CPI, Phase Encoded 
Unrecorded Magnetic Tape, 0.50 Inch 
Recorded Magnetic Tape, 0.50 Inch, 

7-Track, 200 CPI, NRZI 


1.10.005 

1.10.006 
1.10.007 

1.10.013 
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CDC STANDARDS CHECKLIST (REV. E) 



TITLE 


Available 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chooen 
See 2.3 


Waiver 
See 2.4 


Verify/ 
Certify 
Seo 2.5 


Category - ROTATING MAGNETIC MEDIA 




NA 










Jnreeorded Magnetic Six-Disk Pack 

(General, Physical and Magnetic 

Characteristics) 
Unrecorded Single-Disk Cartridge 

(front-Loading, 2200 DPI) 
Interchangeable Magnetic Six-Disk 

rack - Physical and Magnetic 

Cha r act er i s t i cs 
Intercb.nngt.able Magnetic Six-Disk 

Pack - Track Format 
Interchangeable Magnetic Single-Disk 

Cartridge 
Interchangeable Magnetic Eleven-Disk 

Pack 


ANSI X3.46 
ANSI X3.52 

ISO 2864 
ISO 3561 
ISO 3562 
ISO 3564 










Category - CHARACTER RECOGNITION 




NA 










Print Specifications for Magnetic Ink 

Character Recognition 
Print Specifications for Magnetic Ink 

Character Recognition 


ANSI X3.2 
ISO/R 1073 










nank Check Specifications for Magnetic 
Ink Character Recognition 


ANSI X3.3 










Coding of Character Sets for MICR and OCR 

Character Set and Print Quality for 

Optical Character Recognition (OCR-A) 
Character Set for Optical Character 

Recognition (OCR-B) 
♦Optical Character Recognition Character 

Sets 
♦Alphanumeric Character Sets for 

Optical Recognition 
Printing Specifications for Optical 

Character Recognition 


ISO 2033 

ANSI X3.17 
ANSI X3.49 
PIPS PUB 32 
ISO/R 1073 
ISO/R IB 31 










Character Set for Handprinting 
Character Sot for Handprinting 


ANSI X3.45 
FIPS PUR 33 










Specifications for Credit Cards 


ANSI X4.13 










Optical Reader Subsystem Testing 


1.88.001 











*The standard has selectable options 
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CDC STANDARDS CHECKLIST (REV. E) 



TITLE 


Available 
Standards 


Appl i cable 
StMviards 
See 2.2 


Option 
Chcu.c* 
Sec 2.3 


Waiver 
See 2. A 


Verify/ 
C-_ r 1 1 f y 
See 2.5 


Category - DATA COMMUNICATION 














Mode 4C Data Communication Control 
Procedures 


1.10.0?0 


1. ID- 020 








Synchronous Signalling Rates 

Synchronous High Speed Signalling 

Rates 
Synchronous Signalling Rates Between 

Data Terminal and Data Communication 

Equipment 


ansi X3.1 

ANSI X3.36 
FIPS VCB 22 


X3.1 

X3.3b 

PU3 22 








Bit Sequencing of ASCII in Serial-by-Bit 
Data Transmission 

Bit Sequencing of the Code for 

Information Interchange In Serial- 
by-Bit Data Transmission 


ANSI X3.15 
FIPS PU3 10 


X3.15 
PUB lh 








Character Structure and Character Parity 
Scr.se for Serial-by-Bit Data 
Convr.unioation In ASCII 

Character Structure and Character Parity 
Sor.se for Serial-by-Bit Data 
Communication in the Code for 
Information Interchange 

Character Structure for Start/Stop and 
Synchronous Transmission 


ANSI X3.16 

FIPS PU3 17 
ISO* 1177 


X3-lb 

PUtt 17 
ISO 1177 









Character Structure and Character Parity 
Sense for Parallcl-by-Bi t Data 
Communication In ASCII 

Character Structure and Character Parity 
Sense for Parallel-by-Bit Data 
Communication in the Code for 
Information Interchange 


ANSI X3.25 
FIPS PUB 18 


HA 
NA 






Signal Quality at the Interface Between 
Data Processing Terminal Equipment 
and Synchronous Data Communication 
Equipment for Serial Data 
Transmission 


ANSI X3.24 


X3.2M 








Procedures for Using the Control 

Characters of ASCII In Specified 
Data Communication Links 

Basic Mode Control Procedures for 
Data Communication Systems 


ANSI X3.28 
ISO 1745 


X3.2A 
ISO 17MS 








Electrical Characteristics of Balanced 
Voltage Digital Interface Circuits 

Electrical Characteristics of Unbalanced 
Voltage Digital Interface Circuits 

Interface Between DTF. and DCE Employing 
Serial Binary Interchange 

List of Definitions for Interchange 
Circuits Between DTE and Data 
Circult-Terminat ing Equipment 


EIA RS-422 
EIA RS-423 
EIA RS-232 

CCITT V.24 


RS-M22 
RS-M23 
RS-232 

V.2M 
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CDC STANDARDS CHECKLIST (REV. E) 



P-35, 



TITLE 


Available 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chosen 
See 2.3 


Waiver 
See 2.4 


Verify/ 
Certify 
See 2.5 


Category - DATA COM.MUN I CATION (Continued) 














Data Terminal and Data Communication 
Interchange Circuits - Assignment 
of Connector Pin Numbers 

Connector Pin Allocations for Use With 
High-Speed Data Terminals 


ISO 2110 
ISO 2593 


ISO 2110 
ISO 2513 








Basic Mode Control Procedures - Code 

Independent Information Transfer •* 

Basic Mode Control Procedures - 
C< 'implements 

nasic f!r>.1e Control Procedures -• 

•Conversational Information Message 
Transfer 


ISO 2111 
ISO 2628 

ISO 2629 


NA 
NA 

NA 








Use of Longitudinal Parity to Detect • 
Errors in Information Messages 

Determination of the Performance of 
Data Communication Systems 

High-Level Data Link Control 

Procedures - Frame Structure 

Pending AD'CCP Standard 
Ponding ■ CCITT Standard 


ISO 1155 
ANSI X3.44 
ISO 3309 

X.BS t 


NA 

NA 

ISO 3301 
then avail 
Jhon avail 








Category - KEYBOARDS 




NA 










Tan-Key Keyboards for Numeric Data Entry 


1.10.004 










Typewriter Keyboards 


ANSI X4.7 










Alphanumeric Keyboard Arrangements for 

t-r.Cll and OCR 
Keyboard for International Information 

Processing Interchange 
Keyboards for Countries Whose Languages 

have Alphabetic Extenders - 

Guidelines for Harmonization 


ANSI X4.14 
ISO 2530 

ISO 3243 










Function Key Syiibols on Typewriters 
Layout cf Pj.ir.Ling and Function Keys 

vn Typewriters 
Pa.'iic Mrange..:*;nt for the Alphabetic 

Sections of Keyboards 
Principles Governing the Positioning 

of Control Keys on Keyboards 


ISO/R 1090 
ISO/R 1091 
ISO/R 2126 
ISO/R 3244 
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CDC STANDARDS CHECKLIST (REV. E) 



TITLE 


Availablo 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chosen 
See 2.3 


Waiver 
S"i 2.4 


Verify/ 
Certify 
See 2.i 


Category - DATA REPRESENTATION 




/ 










Representation of Calendar Date and 
Ordinal Date for Information 
Interchange 

Calendar Date 

Representation of Ordinal Dates 


ANSI X3.30 
fips run 4 

ISO 2711 


X3.3D 








Cuidolines for Describing Information 
Interchange Formats 


FIPS PUD 20 


NA 








Representation of SI and Other Units in 
Systems With Limited Character Sets 


ISO 2955 


NA 








Representations of Universal Time 
Representations of Time of Day 

Rep. of Local Time of Day 


ANSI X3.51 
ISO 3307 

ANSIX3.M? 


ISO 3307 
X3-M3 








Category - PROGRAMMING LANGUAGES 








• 






COP.OL 
COBOL 
programming Language COBOL 


ANSI X3.23 
FIPS YVli 21 

iso/r. i&f-9 


X3- 23*71 








FORTRAN 

3asic FORTRAN 

Programming Language FORTRAN 


ANSI X3.9 
ANSI X3.10 
ISO/R 1539 


X3.«U76> 








\LGOL-kfJ 


1. 86. 003 


1. fit. 003 








Programming Language PL/I 


ANSI X3.53 


NA 








Category - SPECIAL PURPOSE LANGUAGES 




NA 










;vpt 

Industrial Computer System FORTRAN 

Procedures for Executive Functions 
and Process Input-Output 


ANSI X3.37 
ISA S61.1 
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CDC STANDARDS CHECKLIST (REV. E) 



5 



P-35A 



TITLE 


Available 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chosen 
See 2.3 


Waiver 
See 2.4 


Verify/ 
Certify 
See 2.5 


Category - OPERATING SYSTEMS 














Magnetic Tapo Labels for Information 
Interchange 

Magnetic Tape Error Detection and 
Recovery 

System Error Recovery for Rotating 
Mass Storage 


1.87.002 
1.87.004 
1.87.005 


L.A7.002 
L.S7.D0M 
l,.fl7.0D5 








Category - GENERAL DESIGN 














Component Selection 

Component Qualification 

Quvtlificd Vendor List 

Electronic Logic Packaging 

tticrocircuit. Selection 

Reliability, Availability and 
Maintainability Standards 


1.03.002 
1.03.003 
1.03.005 
1.03.006 
1.03.010 

1.12.000 


L. 03-002 
U 03. 003 
I,. 03-005 
L.03.D0b 
L.03.D10 

1.12. ODD 








Category - ELECTRICAL DESIGN 














General Design Standard for Electronic 
Power Supplies 

Color Coding of Wires, Harnesses and 
Cables 

Cable Classification and Marking 

Computer and Peripheral Equipment 
Design Requirements 

EMC Performance Requirements 

Digital Computet System Grounding 

Analog Computer System Grounding 

E?1I Suppression and Certification 


1.30.001 

1.30.005 
1.30.008 

1.30.011 
1.30.022 
i. 30.023 
1.30.024 
1.30.025 


1.30.001 

U30.00S 
U 30.008 

L- 30. 011 
L- 30. 022 
b. 30. 023 

L- 30-025 









CDC STANDARDS CHECKLIST (REV. E) 



Category - MECHANICAL DESIGN 



Product Identification Emblems 
Operating and Maintenance Meters 
Industrial Design 



:ategory - DOCUMENTAT I ON 



Hardware Configuration Management 

Standards Manual (Entire Contents 
Including 1.01.006) 

Software Configuration Management 

Standards Manual (Entire Contents 
Included) 

Preparation of Microcircuit Procurement 
and Acceptance Test Specifications 

Graphic Symbols for Electrical and 
Electronic Diagrams, 

Reference Desimations for Electrical 
and Electronic Parts and Equipment 

Graphic Symbols for Logic Diagrams 

Logic Diagrams 

Hardware and Software Product" Support 
Manual Standards Manual (Entire 
Contents Included) 

Flowchart Symbols and Usage 



Available 
Standards 



1.20.C06 
1.20.009 
1.20.010 



Anpl i coblo 
St?.n "ords 
See ?.2 



X-EO.ODi 
1.PU.0UA 
1.20.010 



1.01.000 

1.01.100 

1.03.007 

1.41.101 

1.41.102 
1.41.104 
1.41.108 

1.50.000 
1.80.003 



1-D1-D00 

1.01.100 
1.03. 007 

1. Ml. 101 

1. Ml. 102 
1. Ml. 104 

i.m.ioa 

LSD. 000 



Option 
Che.: en 
See 2.3 



Waiver 
See 2.4 



Verify 
Certi f 
See 2. 
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CDC STANDARDS CHECKLIST <REV. B) 



1^-bSi 



TITLE 


Available 
Standards 


Applicable 
Standards 
See 2.2 


Option 
Chosen 
See 2.3 


Waiver 

See 2.4 


Verify/ 
Certify 
See 2.S 


Category - ENVIRONMENTAL 












*-» 


•Application Guidelines 


1.03.201 


1.03.201 


MA 






•Temperature, Humidity and Barometric 
Pressure 


1.03.202 


1.03-202 


TH-R2 
P-Rl 






vibration and Shock 


1.03,203 


1.03.203 








Acoustical Noise 


1.03.204 


1.03.20M 








*Air Cleanlineso 


1.03.205 


1.03. 205 


R3 






Illumination 


1.03.206 


1.03. 20L 








*Input Power and Grounding 


1.03.207 


1.03-207 


FV-OM 
T-Ri 






♦Physical Characteristic 


1.03.209 


1.03-20^ 


R3 






Category - PRODUCT SAFETY 














Jae and Disposal of Capacitors Containing 
Polychlorinated Biphenyl 


1.05.002 


1-05.002 








Product Safety 


1.05.003 


1.05-003 









♦The standard has selectable options 



12-36 
06/C&/7B 



12,0 APPENDICES 

12.9 APPENDIX I - STATEMENTS OF COMPLIANCE 
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l*d DIFIUITI'JH 

1.2 STATtMcM OF COMPLIANCE 



1-2 SiL«ilLDtdI.»iE.CQtIE:Ll&UC£ 

This jr defines the ?Z process of the CDC Cyber d0 
K"D3u;t Line, ar,o as such, conforms *ith the COC Cyber 60 
5/steti J"ehne Definition, with in* lolloping exceotionsi 



Item 

Scientific Perforir.ence 
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SSKTRAl .raHffiBLXftPftCITY A SASGHIOIH. 

The following S3 dual-CPU configuration requirements 
will not be supported. Waiver for these 
requirements has been granted via PAP No. CCFO 01% 
Revision 06 of the AO document will Incorporate this 
change. 

AQ &S 

Maximum Capacity, MRytes 37 16 

Total Bandwidth MBytes/Sec. 256 128 
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aiAIEaEHI^E-GQEELIftL-GE 

This DR docu-nen- conolles *i*h afl CYBER 90 
Maintenance Software objectives sit down within the 
CYBER 80 Architectural Objectives (A3» ?nd ^S/DC 
exct^of those listed in tne fol lowjr.i sections. £ I so 
any waivers or cevii'tions fror, the standards checked 
on the standards chccKlist. 

o Sec» 3»2*r««d A CCS^S disolay is Dh^n^fl To- the 

Initial phase of tne oroject. I f will bo s-oooned 
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the faster display. 

o Z*2*Z Item i CMSE cannot be orovld* tOO*/ customer 
security =ind Still provide nai n tenmc*. It njst be 
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boundaries specified by the Ooerator/Cr. y.e 
Ooerator/CE will have the reoons ; bi I i t y of 
orovidinq the correct JisK ai^ross bou.^caries. 

o Sec- 3. 2-6*2 - System In i? I 3 I j z..f loi - The Cordon 
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•1 o v i c e 1 1) r ~ a i n t e r 



f.*-: - A Jodic^e? i n; jt /:. j rput 
?r^ce us-.ii-? dors not ur>cenr to t>e 



o Sec. 3.1»C - T - r or CY3: y 17C r oi« th,> executive 

will not rr»rj-v'e on-line »~ror rijrtsrrz. The CY c E r ^^ 
eyocutive till r c'f iov-^ t'»e error- r?c->r*s if the 
oo'T-atinn syst'.-i t'j«-. lDoj«»d f-^c^.on a disK ireo t*>ot 
is Known -i~!d ,icce:» > »bl *» to Ci^Ii. 

None. 
None. 
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-Approved-! mtnno e/fl/?fl 
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wP^ 



• ylutM*"/ 
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COMPANY DELEGATE 



0o3 
O.3.? 



OATE 



SlftlEgeNT QF,£flEPLIAKC£ 

This OR document compiles with all CY8ER 60 
Maintenance Software objectives set do*n within the 
CYBER 80 Architectural Objectives (A3) and MS/00 
except those listed in the following sections* Also 
any waivers or deviations from the standards checHed 
on the stondirds checklist* 

AQ_£RU_lli«&_z-E£C£&iJjzas. 

o Sec. 3»2*t»*<» A CC$**<> display Is planned for« the 
Initial phase of the project. It will be sjDOorted 
by CMSE until there Is no longer a reaujrejnt tor 
the faster .display, htf ytd t <V£( i Vrw Ri CM'Sc . 

3.2*2 Item 2 CMSt cannot be orovld* 1002 custcer 
security and still Drovide na Intennce. It -vjst b* 
the responslbl I ty of CMSE. the tests, diagnostics 
and the utilities to stay within the 1isK 3d1ress 
boundaries speci f i ed.hy — the Ot>e - rb t of /CE -r-T^e 
^j0par-34-or^CE_wi I I have -the-rtroorrs-rtr i t t t y u f * 
-P-po-v4-<* •*-*%<*— t-he — G-o^i=^r^)<^t — d4-»H — trd-dne ss m rjrrotynt e-S-*- 

O Sec. 3*2*6.2 - System Initialization - The Comron 

Maintenance Software Executive will reside on the 

same media as the f irmware/cont ro I w3r«» and is 

planned as being the same as the operating system 
fiied ia. 

O Sec. 8.2.3 '- 6th item - A dedicated Input/outout 
device for maintenance usage does not appear to be 
fecslble. 

O Sec. 3*1.2 - 02 - For CYJER 170 now the executive 
will not retrieve on-line error reports. Tho CY'EK 80 
exocurive will rQfrievc the error rooorts if tho 
operating system has logged them on a disK area that 
is known and accessible to CMSE* 

StaQililCdSjL^ExCGLtiiiDS 

CQC-SiaQdaciis 

None* 

tiallg-Qalx^Iol£CQali.qDii 1 1 . an1 ladjutiOc^Slaadficas 
None* 
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1.2 



1.0 
DEFINITION 

Cyber 60 1/0 ts the 1/0 System for the Cyber 60 S2 
and S3 Mainframes. Its main characteristics arez • 

• Common 1/0 Hardware for advanced Cyber 170 N0S and 
N0S/BE and Cyber 60 OS. 

t Plug Compatibility at the channel level with Cyber 
170 Peripherals. 

• S to 20 Peripheral Processors. 

• 6 to 2M Channels. 

• 2 to L, Independent interfaces for connection to the 
Cyber flD Maintenance Channel. 

t lb-Bit internal processing with 12-bit processina 
for the Advanced Cyber 170. 

• Ability to support low cost operator console and 
remote maintenance. 

STATEMENT OF COMPLIANCE 

CY6D 1/0 conforms to the A0/R Rev A exce'pt as follows: 

Item ' • JUL AO/R 

• Mfq. Cost of Target System lOPP/ltCH *(.?.[,*& $S3K 
Allowance for Maintenance Processer Q. 5 



• MTBF Elemental lOPP/ltCH 

• MTBUA -Cat CY80 release) 

• MTBI down CY170 Cat release! 



2lt0 hrs 
170 
M37 



$56K 

2300 hrs 
1032 



NOTE *t Manufacturing Cost Breakdown 

• Pak including nOfc variance *23.5K 

• Cabinet and STC0 „MM«1K 

TOTAL tLV.fclC 






• The most recent manufacturing cost information, 
dated 6 Oct 1977, estimates the 10th unit cost of 
the target system to be 571,246, 
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CYBER AC CCS COUPLCR I>R 



0.0 . Statement of Compliance 

The Cyber 50 ECS Coupler will comply with the aoplicable sec- 
t-o-5 of the Cyber 5G Architectural Objectives/Hcquir«:r. e -n % .-. 
Document-, No. ASKitfifi, Rev. 07 -(second draft revision 5, 
6-15-77> except for the following: 

Section 10-3 ECS Coupler 

o The A0 statement is - Manufacturing cost objective is 
$10K/lQth unit {including cabinet and cabie>. 



The exccDtic 



is b^sed en a Manufacturing Cost Estimate 



{dated 3/c c 1/77> which estimated a ccsr. o* 015 -.eC 
13th production coupler. Fc-.r a cost brer.kccun. 
tion 3.M-1- 



for t>? 
se5 Sf?c~ 
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STATEMENT OF COMPLIANCE 

This DR defines the CEM, and as such, conforms with 
the CDC CYBER 80 System Dasetine Definition, with 
the following exceDtlons. • 

A.O/* 
Reference 



11.1.3 U2.<*.1) 

$5,000 . 



Iten 


This 


. 


DR 




Re f ercnco 


Mfg Cost 




CEM 


3.t».l 




$5,900 


S2 Power 




System 
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